Re: [xine-devel] Segfault in xine_open() with UDP mrl

[Andrew H. <as...@hu...>]

Multi-threaded core dumps?  does that work on 2.6 kernel?  I'm pretty 
sure it doesn't on 2.4, but i suppose there are other OS's out there :) 
  I prefer Michael Roitzsch's old advice:

From: Michael Roitzsch <mroi@us...>
Re: xine segfaulting when playing audio CDs only
2004-03-06 11:09
  > getting held up by numerous messages like this:
  >
  > (gdb) run
  > Starting program: /usr/bin/xine
  > This is xine (X11 gui) - a free video player v0.9.23.
  > (c) 2000-2003 The xine Team.
  >
  > Program received signal SIG32, Real-time event 32.
  > 0x4013e8b4 in pthread_getconcurrency () from /lib/libpthread.so.0
  > (gdb) continue
  > Continuing.
  [snip]
  > Is there a way for me to tell it to just keep continuing? I"ve done this
  > 30 times so far and it just keeps making me type continue.

  Try typing "handle SIGRT32 nostop noprint" before the "run" command.

  Michael

Stephen torri wrote:
> On Fri, 2004-09-10 at 22:17, Rett D. Walters wrote:
> 
>>Hi list,
>>
>>>Could you provide a gdb backtrace of the segfault?
>>>Ideally, you would do this
>>>with a debug-build of xine-lib and your frontend. With
>>>xine-lib, this means
>>>running "make clean debug install-debug" on the source
>>>tree. Then launch your
>>>frontend inside gdb ("gdb <your frontend>", then "run
>>><command line
>>>parameters>" at the prompt). Once it crashes, you will get
>>>the backtrace by
>>>typing "bt" at the prompt. Post the output here.
>>
>>Well, I seem to be having issues doing gdb backtraces of
>>the issue.  When I run gdb like mentioned above, I have to
>>constantly type cont to keep the program executing, only
>>to get to a point where gdb says that program is probably
>>running in another process and further execution is
>>probably not possible, on top of that, the oxine window
>>never comes up either.
>>
>>I get a similiar problem when trying to debug xine-ui.
>>
>>Rett
> 
> 
> If I run into this type of a problem I setup my environment to allow
> core dump files to be produced. A program I tried to debug before would
> not work right inside gdb so a core dump was the only way to obtain
> failure results.
> 
> Set 'ulimit -c unlimited'. Run xine again. Hopefully this time a
> coredump can be obtained. You can run gdb to display the core dump:
> 
> gdb --core=core xine
> 
> At that point you should be able to at least give a backtrace for xine.
> Repeating the steps for oxine should be possible. Its helpful that both
> xine-lib, xine-ui and oxine are build with debugging flag -g set.
> 
> Stephen