Comments (39)
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.
from vimpc.
Also, if 4709014 doesn't fix it, can you give me a backtrace?
from vimpc.
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..?
from vimpc.
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.
from vimpc.
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?
from vimpc.
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.
from vimpc.
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:108I have move recent version.
This is the versions I have on the local computer:
libmpd 11.8.17-1
libmpdclient 2.4-1I 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.
+61 3 9696 6288
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.
from vimpc.
It makes no difference.
from vimpc.
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.
from vimpc.
Is it possible for you to tar up and send me your checkout with the build in place?
from vimpc.
Sure thing: http://japh.se/vimpc_build.tar.gz
from vimpc.
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.
from vimpc.
I'll try it on my other boxes, seeing how this comes closer and closer to being my fault, not yours. :)
from vimpc.
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.
from vimpc.
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
from vimpc.
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.
from vimpc.
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
from vimpc.
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...
from vimpc.
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 qualifiersI'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.
+61 3 9696 6288
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.
from vimpc.
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?
from vimpc.
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).
from vimpc.
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?
from vimpc.
Are you running MPD with a password and does it work if you temporarily disable it?
from vimpc.
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.
from vimpc.
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.
from vimpc.
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.
from vimpc.
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
from vimpc.
Oh, sorry. I should remember to compile it with different libmpdclient version every time.
Try that now.
from vimpc.
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
from vimpc.
Checked out the current git. I can no longer get it to segfault, but instead it uses 100% CPU until I sigkill it.
from vimpc.
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
from vimpc.
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
from vimpc.
For the record - setting host manually with -h doesn't help.
from vimpc.
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?
from vimpc.
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.
from vimpc.
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.
from vimpc.
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.
from vimpc.
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]
from vimpc.
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.
from vimpc.
Related Issues (20)
- password support in $MPD_HOST
- Incorrect version packaged as a Release; "v0.09.2" is actually v0.09.1 HOT 1
- Lyrics fetching doesn't work HOT 4
- Tag for version 0.90.1 HOT 4
- Feature Request/Idea
- error adding symbols: DSO missing from command line HOT 1
- [Feature Request] Library listing
- On systems with libtinfo separate from libncurses: src/vimpc-screen.o: undefined reference to symbol 'keypad'
- New release HOT 3
- Jump to current song in playlist? HOT 1
- Please add Meta- mappings
- Compilation error with --enable-boost: src/clientstate.hpp:125:12: error: ‘thread’ in namespace ‘std’ does not name a type HOT 2
- terminate called after throwing instance of 'std::out_of_range' HOT 1
- Case sensitive search disabled by default.
- Play Next HOT 1
- Library incomplete or not showing up at all HOT 2
- Segmentation Fault in directory HOT 1
- .vimpcrc settings have no effect (not read?) HOT 2
- Ncurses glitch on startup HOT 4
- Segfault when going up directory HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vimpc.