[Pianod] segfault on 'rate neutral'

Michael R. Hines michael at hinespot.com
Sun Dec 9 19:38:00 PST 2012


I'm not sure whether this is a pianod bug or a pianobar bug, can you
advise?

When I use the command "rate neutral", here is the stack trace from GDB
when the segfault occurs:

mrhines at beethoven:~$ gdb pianod
... snip ...
(gdb) run
Starting program: /usr/local/bin/pianod 
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff079d700 (LWP 31471)]

..... snip ..... open terminal, play song and rate neutral.....
snip.....

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff65d5b91 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff65d5b91 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff65d57f6 in strdup () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff690cb21 in json_object_new_string ()
from /usr/lib/x86_64-linux-gnu/libjson.so.0
#3  0x0000000000408183 in PianoRequest ()
#4  0x0000000000404bb3 in BarUiPianoCall ()
#5  0x000000000040699b in run_server.constprop.9 ()
#6  0x0000000000403642 in main ()

- Michael

On Sun, 2012-12-09 at 18:58 -0500, Perette Barella wrote:

> The behavior Peter described suggests it's stuff in the main thread, which would mean it's delaying while getting a new playlist or something like that.  I've seen it do that rarely; it eventually continues when the request times out.  It's rare enough for me I've chalked it up as network or Pandora server dropouts.
> 
> I have also seen playback hang in the middle of a song, while the UI stays responsive, but that's also traceable to network... and it also times out and recovers in a bit.
> 
> 
> 
> As far iOS compiling... I downloaded Titanium, now I need to learn how to use it in my copious spare time :) .  Sounds like you guys are rocking on it though.
> 
> 
> 
> Rethinking of reworking a couple of track status codes because there's some conflation.  Particularly:
> 	103 Playback is stopped.
> 
> This is ambiguous in that there may or may not be a station selected.  Thinking of breaking out/adding 106 (Stopped, no station) to distinguish from 103 (Paused intertrack, station selected).  Thoughts?
> 
> 
> 
> Also, formatting for 101/102 playback status messages is way too busy and confusing:
> 	101 now/length/remain Playing {mix|station} selected-station-name
> 
> Unfortunately, this conflates selected-station with current-track.  Thinking of adding
> 	109 {Mix|Station}: selected-station-name
> 
> There's also the question of whether (and for how long) to retain 101/102 as-is for legacy support.  Thoughts?
> 
> 
> Perette
> 
> _______________________________________________
> Pianod mailing list
> Pianod at lists.deviousfish.com
> http://lists.deviousfish.com/listinfo.cgi/pianod-deviousfish.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deviousfish.com/pipermail/pianod-deviousfish.com/attachments/20121209/c882ada4/attachment-0003.htm>


More information about the Pianod mailing list