I've finally tried to compile xfmedia from latest SVN repository, compile was succeeded including <strings.h> in the mainwin-callbacks, but when I launched xfmedia from terminal it crashed with messages as follows, ** (xfmedia:192232): CRITICAL **: GtkXine: Unable to load audio \ output driver. ** (xfmedia:192232): WARNING **: Not compiled with D-BUS support. \ Remote control interface is not available Note that I'm not sure whether it was caused by xfmedia or xine-lib 1.0, if you think problem has happened another places, please tell me. Reproducible: Always Steps to Reproduce: 1. launch xfmedia from terminal or desktop-menu. Actual Results: It crashes. Expected Results: It shouldn't crash. It was compiled with gcc 4.0.0 (-O2 -g -W -Wall -Wformat=2 -fno-var-tracking), xine-lib 1.0, libexo 0.3.1svn, without D-BUS support.
Created attachment 246 this is the stack trace log for crashed xfmedia
Created attachment 247 this patch fixes compile error on irix This patch fixes compile error on IRIX, desktop file validation error, automake warning when it was ran with autogen.sh. Note that, as for xfmedia.desktop.in, actual error is missing semi-colon just after VideoPlayer at line Categories, so you can modify it as you like.
Sorry I didn't get to this for 0.8.0; it somehow slipped of my mental list. Annnyway... Looks like I fixed the autoconf warning on my own. Does IRIX have both string.h and strings.h, or just the latter? I ask because Linux has both, and using string.h is preferred over strings.h, so I'd rather include string.h if it's present, and strings.h if not. Can you provide info as to what the differences are? What are the compile errors when only string.h is included on IRIX? For the .desktop file, I'll check in your changes later, except that OnlyShowIn is not appropriate for this app. I'm not really sure about the crash. Could you try removing $libdir/xfmedia/plugins/* and see if the crash still occurs?
BTW, it looks like the stack is somewhat corrupted in that trace. Could you get a backtrace with 'thread apply all bt' instead? It's possible that the crash occured in a different thread, and gdb didn't switch properly beforehand (seems to happen all the time).
Created attachment 259 this is the stack trace log for crashed xfmedia with dbx > Does IRIX have both string.h and strings.h, or just the latter? I ask > because Linux has both, and using string.h is preferred over strings.h, > so I'd rather include string.h if it's present, and strings.h if not. > Can you provide info as to what the differences are? What are the compile > errors when only string.h is included on IRIX? IRIX has both of them, the error that must occur without strings.h is mainwin-callbacks.c:1143: error: 'index' undeclared (first use in this function) mainwin-callbacks.c:1143: error: (Each undeclared identifier is reported only once mainwin-callbacks.c:1143: error: for each function it appears in.) then as for difference between string.h and strings.h, the following char *index (const char *s, int c); char *rindex (const char *s, int c); functions are only defined in the strings.h, my lack of knowledge about standards makes me difficult to explain anymore but IRIX's header is being as if there's a labyrinth, MACRO Labyrinth. Indeed, string.h is indirect header for string_core.h which is being located in /usr/include/internal. > I'm not really sure about the crash. Could you try removing > $libdir/xfmedia/plugins/* and see if the crash still occurs? No, without xfmedia-infopipe.so, Xfmedia doesn't crash for the present. > BTW, it looks like the stack is somewhat corrupted in that trace. > Could you get a backtrace with 'thread apply all bt' instead? It's > possible that the crash occurred in a different thread, and gdb didn't > switch properly beforehand (seems to happen all the time). '(gdb) thread apply all bt' does show nothing ... instead I've attached a trace log with dbx, hope this helps. Compilation conditions are same as before other than Glib upgrading (2.6.4 -> 2.6.5).
Ahhh, I see. The problem is actually that I have a variable named 'index', and there's also a function on IRIX named 'index()'. So the real fix is to just change the name of the variable, not change the includes. See, this is why compiler output is useful ^_~. That part should be fixed now. Checked in fixes to the .desktop file. I'm still not sure why the infopipe plugin is causing crashes. I actually am wrapping the xfmedia calls in gdk_threads_enter/leave() pairs.
Created attachment 262 this is the run-time stack trace log with dbx With --debug=full, I've came to conclusion that it doesn't seem your fault in the Xfmedia, rather it was lurking in the Xine library itself. So I'll get CVS code of Xine library later and try to get where problem comes from clearly, sorry for noise.
Can you still crash it without the infopipe plugin loaded? I see from your console output that it's installed again.
Created attachment 263 this is the stack trace log for crashed xfmedia without infopipe > I see from your console output that it's installed again. No Infopipe, no Xfmedia. And yeah, although Xfmedia does start up without infopipe, it'd crash on media file selection whatever I selected (mp3, ogg, mpg, avi). An attached log was mp3 case. Oh, but compiling Xine from latest CVS, I've just remember that Xine on IRIX brings nightmare, in addition gcc4 I have.
Probably xine bug, closing here.