Created attachment 2799 Error message I select a few tracks on thunar, right click on one of them and click the option to play the tracks in the parole media player. The first track is ok, but when the time comes to open the next one parole crashes, output attached. It doesn't matter if I the track starts automatically after the first one has ended or if I double click any track to play it. It crashes anyway. It doesn't seem to matter the file type (I've tested many different track groups including mp3 and ogg files. It doesn't happen with movies though. An important thing to note is that this only happens when visualizations are on. If I disable them then it works as expected, so no big deal, no showstopper, but a bug nonetheless. Another thing that might help debug this is that the problem doesn't appear when I run parole from command line using the --sync option, even if I enable the goom visualizations.
Thanks for taking the time to report this issue. Please do the following steps 1) gdb parole 2) break gdk_x_error 3) run Then do your testing and attach the output of the debugger here, specially when it crashes. Thanks.
Created attachment 2800 gdb output and backtrace There you are. The steps: I configured parole to show the visualizations, closed it. Then I started it as shown in the attachment, dropped a dir full of ogg files into the playlist panel, the first song started and I double clicked the second one. At that point it crashed and I issued the bt command.
Thanks, wasn't very useful, seems that you have parole compiled without debugging support, i couldn't see at which point it crashes, are you able to re-compile parole with the following options. ./configure --prefix=/usr --enable-debug=full then repeat the steps above? please...
Created attachment 2801 gdb output, compiled with debug info Sorry for that. I wasn't able to compile parole 0.2.0.2 with --enable-debug=full, gcc complains about different int types (long long int vs. gint64, probably due to x86_64 being less tested). I guess that's for another bug, however I paste a small portion of the gcc output just for reference. =================== make[4]: se sale del directorio `/home/i92guboj/tmp/parole-0.2.0.2/data/icons/32x32' reamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/xfce4 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/ include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng1 2 -I/usr/include/atk-1.0 -O2 -march=native -pipe -DXFCE_DISABLE_DEPRECATED -Wall -Wextra -Wno-mis sing-field-initializers -Wno-unused-parameter -Wold-style-definition -Wdeclaration-after-statement - Wmissing-declarations -Wredundant-decls -Wmissing-noreturn -Wshadow -Wpointer-arith -Wcast-align -Wf ormat-security -Winit-self -Wmissing-include-dirs -Wundef -Wmissing-format-attribute -Wnested-extern s -fstack-protector -O0 -g3 -Werror -c -o libparolegst_la-parole-gst-iface.lo `test -f 'parole-gst-i face.c' || echo './'`parole-gst-iface.c cc1: warnings being treated as errors parole-gst.c: In function 'parole_gst_query_duration': parole-gst.c:658: error: format '%lld' expects type 'long long int', but argument 3 has type 'gint64 ' parole-gst.c: In function 'parole_gst_get_current_cdda_track': parole-gst.c:2172: error: format '%lld' expects type 'long long int', but argument 3 has type 'gint6 4' =================== However it compiles with --enable-debug, I hope this output is a bit more enlightening than the previous one. I've done a bit more testing and I think it might depend on the media files you choose after all. Maybe it's the gstreamer backend where the problem lies. Both ogg and mp3 fail, but I've tested a few more play lists and I wasn't able to reproduce the problem in some of them. If I can find something more consistent I will let you know. If you need something else just ask, and if you have instructions on how to avoid that gcc error or even a patch I am more than willing to give --enable-debug=full a try. By the way, thanks for all your assistance.
Created attachment 2802 fix printf on 64 bits machines Thanks for debugging, however for me the problem is in GStreamer, but to make sure i attached a patch which should fix compilation issues when --enable-debug=full. What is the version of GStreamer that you have? are you able to try totem? if you can try totem this will be helpful since the overlay code is more or less the same, so if this is reproducible under totem, it is a GStreamer bug, if not, it is my fault. Thanks a lot for taking the time to improve this software.
Sorry for the delay. I just arrived home today, a long day. Totem & deps will compile while I sleep so I can try tomorrow to reproduce this same problem. I'll let you know the outcome. gstreamer is 0.10.25. I will as well try the fix for full debug and answer back with the proper backtrace as soon as possible. Thank you again.
Well, the fix for debug=full works. I'll probably submit a fixed ebuild to the gentoo bugzilla so the rest of gentoo users can use the feature if they want as well. However, now I am not able to reproduce this bug. The only thing that has happened since yesterday is the compilation and installation of totem and its dependencies and the full debug for parole (if it's some timing issue or race condition I guess that could "mask" the bug). I'll try later when I've had my doses of coffee, maybe I am doing something different or some other silly thing, that could be happening as well. Totem works ok as far as I can tell. I've enabled the same goom 2k1 visual on it to test, and I am testing the same files on both players of course.
Confirmed. I can reproduce the bug consistently with --disable-debug and with --enable-debug. I can NOT reproduce it when I configure parole with --enable-debug=full. I can't reproduce the bug in totem either. So, if the second gdb dump (--enable-debug) is not enough info to locate the source of the problem I am ready to do some extra gdb work. Only if you think that it would be worth your time, because I would need some guidance.
Created attachment 2803 More debug output Really weired, i really don't understand why the problem doesn't occur on debug=full. Please try the attached patch, without gdb, and attach the Terminal output here.
Created attachment 2804 Terminal debug output from latest patch There you are. I added a little note in the middle to let you know when I double clicked another track. That's when the player crashed. I can't see anything obvious on that log though.
(In reply to comment #10) > Created an attachment (id=2804) [details] > Terminal debug output from latest patch > > There you are. I added a little note in the middle to let you know when I > double clicked another track. That's when the player crashed. I can't see > anything obvious on that log though. Last thing, load parole with gdb when compiled with --enable-debug=full and with the previous patch. Most weired bug i ever had, but okay hopefully we can debug the problem. Thanks.
Created attachment 2812 GDB with full debug + verbose patch output This is the output with full debug enabled and your verbosity patch applied. There's an (important, I think) new: I have finally made it crash with full debug enabled. I was able to skip one track without a problem, but the next one caused parole to crash (file:///home/i92guboj/Desktop/music/Travis/Invisible%20band/06%20The%20Cage.mp3) By the way and just to be sure, during all this time I've been doing the same steps with totem as well, just in case. I never managed to get it to crash. Thank you.
Thanks, i think we are about to find it, please do the following. parole --xv false then the usual think, play many tracks when vis is enabled. which totem version do you have? because totem is using playbin2 now, parole still uses playbin. Also will be useful to get more information about your VGA and its driver. Thanks.
When I run parole --xv false nothing happens. Is that supposed to just set up parole and then exit back to the shell or should a parole window appear? After running that command, if I start parole normally it crashes just like before. I am not sure I am doing it right, let me know if I should be doing anything else. totem is 2.28.5, if that helps. My graphics driver is current radeon from git, I use an xrandr setup with two monitors, if you need some concrete info just ask. I can provide all kind of dumps, logs or whatever you need. I'll try vesa as soon as I can restart my X server if you think it's worth it. The hardware is this: 01:00.0 VGA compatible controller: ATI Technologies Inc RV630 PRO AGP [Radeon HD 2600 PRO AGP] I'll attach the xdpyinfo below so you can get a general idea about my graphics setup. Let me know if you need anything else.
Created attachment 2814 xdpyinfo output
I just checked the parole rc file, and it has a line like this on it: enable-xv=false So I guess the command above worked. It continues crashing though.
(In reply to comment #16) > I just checked the parole rc file, and it has a line like this on it: > > enable-xv=false > > So I guess the command above worked. It continues crashing though. Okay, now a debugger log from gdb will help a lot, "enable-xv=false" without X video support.
Created attachment 2815 gdb output with enable-xv=false I hope this is what you asked for. Thanks.
Created attachment 2816 Ignore expose on ready state Please try out this patch, if it still crashes, then attach a gdb output here, nevermind with --enable-xv false or true.
Created attachment 2817 gdb dump with the ignore expose on ready state patch
with the same configuration, try to run parole from the terminal (without gdb) parole --gst-debug-level=3 then attach everything you see here. Sorry but i still don't find any relevant error, what is bad is that i can't reproduce it on my system.
Created attachment 2818 parole --gst-debug-level=3 --gst-debug-no-color > gst_debug.txt 2>&1 There you are. I removed color codes to clean the output a bit. I really can't see anything that's obviously wrong either, besides a lot of sync warnings. I hope your trained eye can see something more than that. Please, don't throw too much time into this if I am the only one having this problem (unless you are naturally inclined to do so). I really don't care that much about visualizations, and I can always use totem if I need them some day for a reason. The problem might lie in whatever combo of factors, bearing in mind that this is Gentoo and not a regular binary distribution. Whatever the outcome might be, thanks again for everything. :)
Created attachment 2822 Use gdk threads init to avoid race conditions. Please try out the latest patch, BTW which gtk version do you have?
I am trying that patch but when I do so parole hangs when starting. I can't click anything on the client part of the interface. I can only interact with the window frame to kill the player window. It doesn't play anything either. It doesn't make a difference if I disable the visualizations. Gtk+ is 2.18.6
Created attachment 2824 Protect critical overlay function. Ignore the previous patch, please try out this new one. thanks.
Created attachment 2825 Another gdb dump against the latest patch This patch worked however it doesn't fix the problem. It still crashes at the same point. I attach the gdb output just in case. I am trying to do some extra debugging with gdb to see if I can find the exact point where the crash happens, I will try to request some help at the Gentoo forum and see if there's someone else who can reproduce this bug. Thank you.
Created attachment 2837 Remove visual colormap bits. Appreciate your help on this issue, please try this patch, just tell me if it works or not, no need to attach outputs.
Created attachment 2838 Explicitly set display name. Also try out this patch. thanks!
Sorry for the silence these last days. I wasn't able to find anything useful about this bug. I applied the patches (I had to remove the first trunk on the display name patch 'cause it seems to be malformed, it didn't apply otherwise). After recompiling it doesn't seem to crash now, I need to do more testing however, as the issue doesn't seem to appear always under the same conditions. I'll keep you informed. For now, it seems to work ok.
Ok, the patches didn't work, but I think I have something for you. I have been wondering why the heck I even I, the discoverer of the bug, couldn't reproduce the bug consistently every day I tried. I think I have found a consistent way to reproduce it. This is what I do: Enable the Goom visualization. Enable the systray plugin. Enable the window title plugin. Put some tracks into the playlist. Randomly double click them until it crashes. I will continue doing some tests, but in my experience up till now, the crash only occurs when goom, systray and window title are all enabled at the same time. Some times, after it crashes, when I open parole again the systray plugin has been disabled (and I didn't do it). I guess it's parole or the plugin itself which turns it off to prevent further problems (?). I'll keep you posted.
Created attachment 2847 My config files for parole and plugins I attach the config files for parole and the plugins (systray only for what it seems) in case you want to test with this config. You can uncompress it at ~/ I can reproduce the bug consistently with this config by just filling the playlist with a few tracks and double clicking them around like mad.
I can't reproduce this bug and it's been a long time since you reported it. Since there have been many changes to Parole recently, I'd like to ask you to try and reproduce it again, marking it as worksforme for now.