segfault about vimpc

[richo]

Do you have an mpd running?

It segfaults on failure to connect (The connect code was written upstream, and the checks that the socket opened ok occur seperately to opening).

I just checked in some more code that should help with the problem.

[richo]

Also, if 4709014 doesn't fix it, can you give me a backtrace?

[trapd00r]

I have mpd running on a remote host. I have $MPD_HOST and $MPD_PORT etc set.

I tried just after you pushed, and the issue still remains.
I am not sure how to generate a backtrace..?

[richo]

Very odd.

If you start vimpc in gdb, then execute

run
bt

At the gdb prompt it will spit out a backtrace, however I think I have a hunch about where it's going wrong.

[richo]

I'll definitely need a backtrace to check it out, I just double checked with a remote mpd (I kinda cheated, and just bound mpd to an interface alias) and it starts ok, but also doesn't segfault any more if mpd isn't there.

Is there any chance this is an old checkout?

[trapd00r]

Here it is:

 Program received signal SIGSEGV, Segmentation fault.
 0xb7f78d17 in mpd_status_get_queue_version () from /usr/lib/libmpdclient.so.2
(gdb) bt
  #0  0xb7f78d17 in mpd_status_get_queue_version () from /usr/lib/libmpdclient.so.2
  #1  0x0804d9a4 in Mpc::Client::CheckForUpdates (this=0xbfffdd94) at src/mpdclient.cpp:382
  #2  0x08058f2b in Main::Vimpc::Run (this=0xbfffdd3c) at src/vimpc.cpp:87
  #3  0x0804d020 in main (argc=1, argv=0xbfffdea4) at src/main.cpp:108

I have the recent version of vimpc.

This is the versions I have on the local computer:

libmpd 11.8.17-1
libmpdclient 2.4-1

I am running mpd 0.17-git on the server.

[richo]

Ok,

I'll chase this up on my way home tonight.

Out of curiosity can you specify the host with -h [HOST] instead of using
the environment variable?

Cheers

Rich

On Wed, Sep 14, 2011 at 12:07 AM, Magnus Woldrich <
[email protected]>wrote:

Here it is:

Program received signal SIGSEGV, Segmentation fault.
0xb7f78d17 in mpd_status_get_queue_version () from

/usr/lib/libmpdclient.so.2
(gdb) bt
#0 0xb7f78d17 in mpd_status_get_queue_version () from
/usr/lib/libmpdclient.so.2
#1 0x0804d9a4 in Mpc::Client::CheckForUpdates (this=0xbfffdd94) at
src/mpdclient.cpp:382
#2 0x08058f2b in Main::Vimpc::Run (this=0xbfffdd3c) at
src/vimpc.cpp:87
#3 0x0804d020 in main (argc=1, argv=0xbfffdea4) at src/main.cpp:108

I have move recent version.

This is the versions I have on the local computer:

libmpd 11.8.17-1
libmpdclient 2.4-1

I am running mpd 0.17-git on the server.

Reply to this email directly or view it on GitHub:
https://github.com/richoH/vimpc/issues/1#issuecomment-2082036

Rich Healey
Systems Administrator & Web Engineer
Box & Dice Software Pty Ltd.
[phone]
www.boxdice.com.au

Reduce your environmental footprint, print only if necessary. Caution: this
message may contain privileged and confidential information
intended only for the use of the addressee named above. If you are not the
intended recipient of this message you are hereby notified
that any use, dissemination, distribution or reproduction of this message is
prohibited. If you have received this message in error please
notify Box+Dice Software Pty Ltd immediately. Any views expressed in this
message are those of the individual sender and may not
necessarily reflect the views of Box+Dice Software.

[trapd00r]

It makes no difference.

[richo]

I've just had a look, I don't see where that would get called, the failed connection should have been detected and a warning generated.

I'm going to push a debug branch tonight, I'll ask you to send me the output from it.

In the meantime, I realised that svn is going to cause some issues so I've done a forced push to master reverting it to svn HEAD and moved my work into richo-dev. You'll need to checkout that branch in future.

[richo]

Is it possible for you to tar up and send me your checkout with the build in place?

[trapd00r]

Sure thing: http://japh.se/vimpc_build.tar.gz

[richo]

Very very strange. I just untarred what you sent me, relinked it (against my libs) with

g++    -g -O2   -o vimpc src/vimpc-algorithm.o src/vimpc-buffers.o src/vimpc-main.o src/vimpc-mpdclient.o src/vimpc-player.o src/vimpc-screen.o src/vimpc-settings.o src/vimpc-song.o src/vimpc-vimpc.o src/buffer/vimpc-browse.o src/buffer/vimpc-library.o src/mode/vimpc-command.o src/mode/vimpc-inputmode.o src/mode/vimpc-normal.o src/mode/vimpc-search.o src/window/vimpc-browsewindow.o src/window/vimpc-console.o src/window/vimpc-help.o src/window/vimpc-librarywindow.o src/window/vimpc-modewindow.o src/window/vimpc-playlistwindow.o src/window/vimpc-scrollwindow.o src/window/vimpc-selectwindow.o src/window/vimpc-window.o -lpcre -lpcrecpp   -lmpdclient   -lncursesw

and it successfully connects to a remote mpd, and fails gracefully if it can't.

I will get a later version of libmpdclient (you're a minor version ahead of me) and try that tonight. Thanks for the report.

[trapd00r]

I'll try it on my other boxes, seeing how this comes closer and closer to being my fault, not yours. :)

[richo]

If you could that would be good. It may be an issue in the latest version of libmpdclient.

The other test I can think of doing is adding some arbitrary hostname in /etc/hosts and then invoking either MPD_HOST=arbitraryname vimpc or vimpc -h arbitraryname and seeing if that works, it may help to narrow down what the issue is.

I had that exact error a while back because it wasn't checking the validity of the socket before interacting with it, but it should work, especially if there is a backend there for it.

[trapd00r]

On the server running MPD (MPD_HOST being localhost, building from richo-dev):

#0  0x00007ffff7795be0 in mpd_status_get_queue_version () from /usr/lib/libmpdclient.so.2
#1  0x0000000000406b66 in Mpc::Client::QueueVersion (this=<optimized out>) at src/mpdclient.cpp:544
#2  0x0000000000406e2a in Mpc::Client::CheckForUpdates (this=0x7fffffffc338) at src/mpdclient.cpp:382
#3  0x0000000000411cc9 in Main::Vimpc::Run (this=0x7fffffffc290) at src/vimpc.cpp:87

I accidently builded from master first, and surely the output isn't the same:

#0  0x00007ffff7795be0 in mpd_status_get_queue_version () from /usr/lib/libmpdclient.so.2
#1  0x0000000000406a36 in Mpc::Client::QueueVersion (this=<optimized out>) at src/mpdclient.cpp:531
#2  0x0000000000406cfa in Mpc::Client::CheckForUpdates (this=0x7fffffffc378) at src/mpdclient.cpp:369
#3  0x00000000004077f7 in Mpc::Client::Connect (this=0x7fffffffc378, hostname=..., port=0) at src/mpdclient.cpp:79
#4  0x0000000000411b59 in Main::Vimpc::Run (this=0x7fffffffc2d0) at src/vimpc.cpp:87
#5  0x0000000000405176 in main (argc=1, argv=0x7fffffffc528) at src/main.cpp:95

[trapd00r]

Progress...

MPD_HOST=foobar ./vimpc

works fine (that is, it fails to connect).

I tried

:connect 192.168.1.128:6600 

but it seems trying to connect to arbitary places from within vimpc isn't allowed.

[richo]

Good news. I replicated the issue :)

It happens when mpd goes away during a session, vimpc doesn't correctly check the validity of the socket before playing with it and it dies (so it connects initially, then falls over).

I'll fix this tonight.

As an aside, I'm 99% sure that the syntax would be :connect 192.158.1.128 6600

[trapd00r]

Sorry, but that makes it not compilable:

src/mpdclient.cpp: In member function ‘bool Mpc::Client::Connected() const’:
src/mpdclient.cpp:475:15: error: passing ‘const Mpc::Client’ as ‘this’ argument of ‘void Mpc::Client::CheckError()’ discards qualifiers

I've tried debugging it myself but I'm not really home with cpp...

[richo]

Yeah I know, I dumb thumbed it in. I have removed that commit from the
richo-dev branch.

I have another patch which kinda fixes the problem but not completely. I
should have a working fix in ~6 hours when I get home.

On Wed, Sep 14, 2011 at 6:12 PM, Magnus Woldrich <
[email protected]>wrote:

Sorry, but that makes it not compilable:

src/mpdclient.cpp: In member function bool Mpc::Client::Connected()
const:
src/mpdclient.cpp:475:15: error: passing const Mpc::Client as this
argument of void Mpc::Client::CheckError() discards qualifiers

I've tried debugging it myself but I'm not really home with cpp...

Reply to this email directly or view it on GitHub:
https://github.com/richoH/vimpc/issues/1#issuecomment-2090838

Rich Healey
Systems Administrator & Web Engineer
Box & Dice Software Pty Ltd.
[phone]
www.boxdice.com.au

Reduce your environmental footprint, print only if necessary. Caution: this
message may contain privileged and confidential information
intended only for the use of the addressee named above. If you are not the
intended recipient of this message you are hereby notified
that any use, dissemination, distribution or reproduction of this message is
prohibited. If you have received this message in error please
notify Box+Dice Software Pty Ltd immediately. Any views expressed in this
message are those of the individual sender and may not
necessarily reflect the views of Box+Dice Software.

[richo]

Hilariously, without knowledge of this bug the upstream author fixed it (I was looking in the wrong place)

Can you build the latest master and confirm that it's ok?

[trapd00r]

Now it starts properly. However:

I can't see what I'm typing in ex mode. I can't see any response. The command is executed, though.
I can't see my playlist or browse my library.
It doesn't seem to be connected to my mpd at all. When executing commands such as :next, nothing happens (and I can't see any output).

[boysetsfrog]

I am currently able to get vimpc in a state where i cannot see what is being typed in ex mode, but only when it is trying to connect, but before it ultimately times out. So i will change it so you can atleast see what you are typing when you are in this state.

Do you have a long default timeout set somehow?
Is the ex mode bar visible at all (the last line below the blue status bar)?
Do you have a playlist, browse, etc tab in the top bar visible?
Do normal mode commands like 'Alt+1', 'Alt+2' etc, work?

[boysetsfrog]

Are you running MPD with a password and does it work if you temporarily disable it?

[trapd00r]

Hi,

connection_timeout is set to 60.
The ex mode bar is visible, and I can see the cursor in it, though it never moves.
I do have the playlist, browse tabs.
Yes, alt+1 etc does work.

I am not using a password.

[boysetsfrog]

Hi, trapd00r

Unfortunately i have had no luck replicating this behaviour. I have improved the error handling a bit and cleaned things up a bit, so it's worth trying again (from the master). I will keep looking into this though.

[boysetsfrog]

Actually if you could run it in gdb, wait till it is in the state you describe, hit Ctrl+C and then send me a backtrace that would be wonderful.

[trapd00r]

I can't even compile it no more:

In file included from src/main.cpp:25:0:
src/vimpc.hpp:88:7: error: ‘Search’ in namespace ‘Mpc::Ui’ does not name a type
src/vimpc.hpp:89:7: error: ‘Screen’ in namespace ‘Mpc::Ui’ does not name a type
src/main.cpp: In function ‘int Mpc::main(int, char**)’:
src/main.cpp:78:28: error: ‘Mpc::Main::Project’ has not been declared
src/main.cpp:83:28: error: ‘Mpc::Main::Project’ has not been declared
src/main.cpp:88:28: error: ‘Mpc::Main::Project’ has not been declared
src/main.cpp: At global scope:
src/main.cpp:114:1: error: expected ‘}’ at end of input

[boysetsfrog]

Oh, sorry. I should remember to compile it with different libmpdclient version every time.

Try that now.

[trapd00r]

Here we go:

Program received signal SIGINT, Interrupt.
0xb7fe1424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7d6667b in poll () from /lib/libc.so.6
#2  0xb7f54932 in _nc_timed_wait () from /lib/libncursesw.so.5
#3  0xb7f34680 in _nc_wgetch () from /lib/libncursesw.so.5
#4  0xb7f349e1 in wgetch () from /lib/libncursesw.so.5
#5  0x08050927 in Ui::Screen::WaitForInput (this=0xbfffce40) at src/screen.cpp:511
#6  0x0805ac13 in Input (this=0xbfffce34) at src/vimpc.cpp:162
#7  Main::Vimpc::Run (this=0xbfffce34, hostname=..., port=0) at src/vimpc.cpp:125
#8  0x0804d0d3 in main (argc=1, argv=0xbfffcfc4) at src/main.cpp:110

[trapd00r]

Checked out the current git. I can no longer get it to segfault, but instead it uses 100% CPU until I sigkill it.

[boysetsfrog]

Hi trapd00r.

Unfortunately i haven't been able to replicate any of the issues that you have been having, i have run vimpc with a number of different versions of libmpdclient and mpd without fail. I would be interested to know what version of ncursesw you are running though. And i guess if you could do the interrupt and backtrace again, since it sounds as though it is caught in an infinite loop, that would be helpful.

Thanks

[trapd00r]

It seems like I'm the only one affected by this issue. I'd really like some company, so trying to get other people running arch to try this out and report back. :)

Not sure what ncursesw is - I am running ncurses 5.8 though.

Is the backtrace still useful even though I have to kill vimpc by hand?

#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7d6667b in poll () from /lib/libc.so.6
#2  0xb7f54932 in _nc_timed_wait () from /lib/libncursesw.so.5
#3  0xb7f34680 in _nc_wgetch () from /lib/libncursesw.so.5
#4  0xb7f349e1 in wgetch () from /lib/libncursesw.so.5
#5  0x08051937 in Ui::Screen::WaitForInput (this=0xbfffcd08) at src/screen.cpp:538
#6  0x0805bb23 in Input (this=0xbfffccfc) at src/vimpc.cpp:151
#7  Main::Vimpc::Run (this=0xbfffccfc, hostname=..., port=0) at src/vimpc.cpp:114
#8  0x0804d643 in main (argc=1, argv=0xbfffce94) at src/main.cpp:110

[trapd00r]

For the record - setting host manually with -h doesn't help.

[richo]

I will set up an Arch vm this week and see if I can replicate.

Is there any particular release or version I should be installing?

[trapd00r]

No; arch is rolling release, so it doesn't matter what medium or version you use to install, just issue

pacman -Syu

so you'll be up to date.

[boysetsfrog]

I actually run arch myself (64 bit), and do all my vimpc development on my arch desktop. I do have a more recent ncurses than yourself though, currently using 5.9, but i am not sure whether it's worth trying, i am also running 5.7 on the debian machine i run vimpc.

I think the backtrace is still useful, because i would suppose that if it is getting to 100% cpu usage that as i said it is in an infinite loop, and from the backtrace i can atleast determine what that loop might be. Unfortunately looking at that backtrace it looks like it is the main application loop, i do have a couple of things i am going to try though, i will keep you posted.

[boysetsfrog]

I changed the way some the ncurses stuff works, I am not sure how much it will help, but it should atleast (hopefully) reduce the impact on the cpu load.

[trapd00r]

Guess what... just checked out master again and - it works!

Well, at least somewhat. If I add ~1000 songs to the current playlist, it can no longer connect to mpd:

E3: Failed to connect to server, please ensure it is running and type :connect <server> [port]

[richo]

I believe that's the same issue I have when connecting to a remote MPD.

I'll try to track it down, I think it relates to a timeout while waiting on mpd to return data.