| Summary: | xmms segfaults when playing ogg vorbis via arts | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Terje Bergström <terje> |
| Component: | Current packages | Assignee: | Brandon Low (RETIRED) <lostlogic> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | ulmi01 |
| Priority: | High | ||
| Version: | 1.2 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Terje Bergström
2002-06-29 04:08:13 UTC
hoorray, yes newlines are preserved with mozilla, I believe it has to do with how the bugzilla forms are designed (specific number of pre-existing lines in the bug box) and konqueror only using the first of those premade lines for any text entered... anywho, about the bug, I'm going to have to go do some OGG encoding to test, hopefully I'll be able to reproduce and fix later today. reproduced, I'm going to work on releasing a cvs snapshot ebuild for libogg that will fix this. I believe there's a bigger problem with the xmms-arts plugin. I experience (personally) the same/similiar behavior (segfault after attempt to change song) with the arts plugin enabled. Switching to OSS or another output plugin solves the problem. The bugzilla at bugs.xmms.org has quite a few closed (INVALID/WONTFIX) bugs, and the author appears to be MIA. (Note the ebuild file has the homepage commented out.) Further some comments posted off the plugins page at the xmms.org site (http://www.xmms.org/comments.html?show=P101) show similiar problems (bottom==newest post). (Apologies for spam -- psuedo workaround) While digging around for a new version of the arts module, I did find that using the OSS output plugin will work under artsdsp... Just envoke xmms as "artsdsp xmms", and it'll kludge it's way into arts support. (Kinda) :) The issue is in the libogg library, as the reporter mentioned. THere will be a new version of said library shortly, and at that time it will hit portage and you will no longer experience this problem, that is why the xmms-arts people WONTFIX it and such. Please be patient. within 1/2 hour, ogg-vorbis-1.0 packages will all be in rsync, please retest this with those versions as it should work perfectly, and report your results here. Thanks for your patience on this one! I emerged the new version and tried recompiling everything that depends on libvorbis, and even re-emerged arts. That's why it took some time. Sorry, but xmms still crashes when I try to switch to the next song with the arts output plugin. Now the crashing point is different, though: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 4101 (LWP 13845)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x410290e6 in __static_initialization_and_destruction_0(int, int) () from /usr/kde/3/lib/libartsflow.so.1 #2 0x4102ecaa in _GLOBAL__D_gslMainLoop () from /usr/kde/3/lib/libartsflow.so.1 #3 0x41027537 in __do_global_dtors_aux () from /usr/kde/3/lib/libartsflow.so.1 #4 0x4109e769 in _fini () from /usr/kde/3/lib/libartsflow.so.1 #5 0x40749a87 in _dl_close () from /lib/libc.so.6 #6 0x40749793 in _dl_close () from /lib/libc.so.6 #7 0x40553f4c in dlclose_doit () from /lib/libdl.so.2 #8 0x4000a1a8 in _dl_catch_error () from /lib/ld-linux.so.2 #9 0x40554286 in _dlerror_run () from /lib/libdl.so.2 #10 0x40553f22 in dlclose () from /lib/libdl.so.2 #11 0x402d8ba4 in sys_dl_close () from /usr/kde/3/lib/libartsc.so.0 #12 0x402d7dca in lt_dlclose () from /usr/kde/3/lib/libartsc.so.0 #13 0x402d667b in arts_free () from /usr/kde/3/lib/libartsc.so.0 #14 0x40860355 in artsd_loop () from /usr/lib/xmms/Output/libartsout.so #15 0x40031a83 in pthread_start_thread () from /lib/libpthread.so.0 #16 0x40031b0f in pthread_start_thread_event () from /lib/libpthread.so.0 with latest ogg and arts I am no longer having this problem... can you still confirm this bug with everything upgraded and all relevent binaries recompiled? blah, I lied, it does still break on song change. *back to the drawing board* I obesrve the same thing: when using the arts plugin for xmms, the whole thing segfaults at a change of song. It ONLY occurs using GCC 3.1 (I have a parallell system working on 2.95 that runs problem-free). There's NO relationship with ogg files: Lame encoded mp3's behave exactly the same. There's also NO relationship with Alsa (kernel sound also produces a segfault). versions: media-sound/alsa-driver-0.9.0_rc2 media-sound/xmms-1.2.7-r11 media-sound/xmms-arts-0.4-r3 I think this is related to the problem I am having. I've had this problem since upgrading to gcc 3.x. It happens regardless of the file type being played. It is solely tied to the arts plugin. If I try to change songs (forward, previous, etc.) or press stop, xmms dies. However if I change the output plugin to esd it works fine. well I'm not getting segfaults but I am now getting freezes, unfortunately I think this is a problem with the xmms-arts upstream plugin (from reading the xmms page) the plugin appears to have issues with artsd in kde3... Brandon, now that concensus has come circle back to what I discussed in comment 3 -- can I recommend the ebuild be modified to require kde<3 and/or removed/masked? The author of the plugin is MIA, and noone has steped up to take his place. yes, I am going to mask it at some time in the near future... when I have time. I've encountered the same problems when playing MP3 through xmms and arts, and
I've found a way to fix it:
// BEGIN DIFF
--- xmms-arts-0.4-orig/audio.c 2000-11-21 05:24:25.000000000 +0100
+++ xmms-arts-0.4-new/audio.c 2002-10-02 12:46:57.000000000 +0200
@@ -242,6 +242,12 @@
{
gint length, cnt;
+ int errorcode;
+ errorcode = arts_init();
+ if (errorcode < 0) {
+ fprintf(stderr,"arts_init error: %s\n",
arts_error_text(errorcode));
+ pthread_exit(NULL);
+ }
while (going)
{
// END DIFF
For me, this works perfectly and I've had no further problems, don't ask me
how or why, but it seem to work.
(Someone should really rewrite the arts-plugin, it's horribly bad written)
Comment #15 worked also for me. ok, sorrya bout the delay, updating in portage NOW I agree that it needs re-coding, might want to see if you can dig up the upstream developer and give them that patch... or find SOMEONE SOMEWHERE to do makexor it work. I believe the problem is caused by xmms-arts tries to spawn it's own thread while xmms is not running at realtime-priority, to hold an audio-buffer. I really doubt that is this is really nescesarry when arts by itself holds an audiobuffer in relation to the system's performance. I think the problem is that when using newer versions of gcc, kde (and therefore also arts) and xmms-arts it deals with resource allocation in different ways, and I think that is what causes the crashes and hangings. (BTW. Not to be picky, but why is Mauricio Lima Pilla credited in the Changelog? :-) becauseI'm dumb, thanks. This actually fixes the problem for me. Thanks! |
