Segfault on player-prev

[Philipp Hartwig]

Hi,

with git HEAD and an empty ~/.cmus, the following steps produce a segfault for
me:

First
set repeat=true
set aaa_mode=album

Then add some album, play the first track and execute player-prev. The track
selection should wrap around to the last track of the album, but instead cmus
crashes.

I've compiled cmus with DEBUG=2, and a cmus-debug.txt is created, but it
doesn't contain anything related to the crash (I've attached it anyway; this
is from an album where Der_Fischer_und_seine_Seele2.mp3 is the first track).
If you cannot reproduce the problem, I'll be happy to look into creating a
meaningful backtrace with gdb or whatever helps you.

Regards,
Philipp

[Gregory Petrosyan]

Post by Philipp Hartwig
with git HEAD and an empty ~/.cmus, the following steps produce a segfault for
First
set repeat=true
set aaa_mode=album
Then add some album, play the first track and execute player-prev. The track
selection should wrap around to the last track of the album, but instead cmus
crashes.
I've compiled cmus with DEBUG=2, and a cmus-debug.txt is created, but it
doesn't contain anything related to the crash (I've attached it anyway; this
is from an album where Der_Fischer_und_seine_Seele2.mp3 is the first track).
If you cannot reproduce the problem, I'll be happy to look into creating a
meaningful backtrace with gdb or whatever helps you.

What branch are you using — master or pu? Also, backtrace would
definitely be helpful, if it is not too much to ask for.

Thanks a lot for reporting the bug.

Gregory

[Philipp Hartwig]

Post by Gregory Petrosyan
What branch are you using — master or pu?

master

Post by Gregory Petrosyan
Also, backtrace would definitely be helpful, if it is not too much to
ask for.

Here it is:

#0 0x0000000000426e45 in tree_track_info (track=0xffffffffffffffa8) at lib.h:39
#1 0x00000000004278c1 in lib_set_track (track=0xffffffffffffffa8) at lib.c:341
#2 0x0000000000427a42 in lib_set_prev () at lib.c:385
#3 0x000000000040f629 in cmus_prev () at cmus.c:98
#4 0x0000000000412b33 in cmd_p_prev (arg=0x0) at command_mode.c:1298
#5 0x0000000000415a57 in run_parsed_command (cmd=0xe4ccd0 "player-prev", arg=0x0) at command_mode.c:2794
#6 0x0000000000415a9f in run_command (buf=0xdef724 "player-prev") at command_mode.c:2808
#7 0x000000000042663e in handle_key (b=0xdef710, k=0x446a80) at keys.c:578
#8 0x0000000000426791 in normal_mode_ch (ch=122) at keys.c:625
#9 0x000000000043dee7 in handle_ch (ch=122) at ui_curses.c:1957
#10 0x000000000043e126 in u_getch () at ui_curses.c:2044
#11 0x000000000043e62f in main_loop () at ui_curses.c:2153
#12 0x000000000043eda8 in main (argc=1, argv=0x7fffffffe800) at ui_curses.c:2445

Here is what I get when setting a breakpoint in lib_set_track:

(gdb) p *track
Cannot access memory at address 0xffffffffffffffa8

If you need further information just let me know.

Regards,
Philipp

[Gregory Petrosyan]

Post by Gregory Petrosyan

Post by Gregory Petrosyan
What branch are you using — master or pu?

master

Post by Gregory Petrosyan
Also, backtrace would definitely be helpful, if it is not too much to
ask for.

Here it is: …
If you need further information just let me know.

Thanks for the excellent bug report — I've reproduced and fixed the
problem. Can you please double-check that it is gone by updating to
latest master (or maint)?

Gregory

[Philipp Hartwig]

Post by Gregory Petrosyan
Thanks for the excellent bug report — I've reproduced and fixed the
problem. Can you please double-check that it is gone by updating to
latest master (or maint)?

Indeed everything works as expected with latest master.

Awesome, that was fast, thank you very much.

Regards,
Philipp

[Brandon McCaig]

Post by Philipp Hartwig
Hi,

Hello,

Post by Philipp Hartwig
with git HEAD and an empty ~/.cmus, the following steps produce

/nitpick

Instead of saying HEAD, which is arbitary, and even if you assume
the head of the master branch can easily change between time of
writing; it makes more sense to give the SHA1 hash of HEAD. :)
That also eliminates the question of which branch you're on too
because it's not relevant to get there (albeit, it can be
relevant for other reasons). The important part is where in the
DAG you are though. :) An easy way to turn a ref into a SHA1 is
git-rev-parse: `git rev-parse HEAD'.

Regards,