Opened 18 years ago
Closed 17 years ago
#2485 closed defect (duplicate)
mythmusic segmentation fault, not when running through gdb
Reported by: | Owned by: | Isaac Richards | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythmusic | Version: | 0.20 |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
I'm experiencing occasional, random segmentation faults in MythMusic. I'm currently running the 0.20 release version of mythtv and mythplugins.
The segfaults seem to be occurring when starting a new track. Sometimes it happens right when I enter mythmusic, sometimes it plays fine for hours before segfaulting. All of this is while playing in random shuffle mode, I'm unsure whether any other shuffle modes have the same problem since I rarely use them.
Initially I thought that I might have one or two corrupted tracks that caused segfaults when mythmusic tried to load them, but I went through my entire collection today and all of them started playing fine.
Unfortunately while running mythfrontend through gdb in an attempt to get a backtrace I've been unable to replicate the segfault. I'll leave it playing the rest of tonight and all of tomorrow to make sure, but it seems that running through gdb prevents the random segfaults.
I know the lack of a backtrace will probably make this very hard to debug, what other information can I provide to help? Other than this one problem mythtv is rock solid stable, and the system has been up for over 29 days now so it is not a faulty RAM problem.
Attachments (3)
Change History (16)
comment:1 Changed 18 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 follow-up: 3 Changed 18 years ago by
On Steven Adeff's suggestion I tried running "ulimit -c unlimited" prior to starting the frontend and it seems to prevent the segfault.
comment:3 Changed 18 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Nevermind, it just segfaulted. Fortunately the ulimit thing seems to have let it create a core dump. I'll attach the core file and the gdb backtrace I got from it.
Replying to vbrunini@mit.edu:
On Steven Adeff's suggestion I tried running "ulimit -c unlimited" prior to starting the frontend and it seems to prevent the segfault.
comment:4 Changed 18 years ago by
Also seeing FE segfault in mythmusic with latest SVN. Seems to be caused by the visualisation plugins - if I leave these off, mythmusic runs without fault. In particular, goom seem to trigger it more often than the others. Using epia1300/cn400 with latest openchrome drivers. Will run under gdb and attach a trace.
comment:5 Changed 17 years ago by
I finally got a full backtrace running in gdb, I'm attaching it now.
comment:7 follow-up: 8 Changed 17 years ago by
I finally got some free time this weekend and applied the patch. Mythmusic is currently going, has been for ~2 hrs without a crash. I'll leave it on for all of tomorrow to make sure it's working and let you know.
Replying to myth@eskil.org:
See ticket#2557, I think this is the same problem, and the patch I've attached to ticket#2557 seems to fix it. If you could also try out the patch and see if it fixes the segfault, that'd be awesome.
comment:8 Changed 17 years ago by
Well I'm still getting the crashes, I haven't gotten a backtrace or run myth through gdb yet so I can't be sure it's the same problem, but the behavior is identical so I'm fairly sure it is.
comment:9 follow-up: 10 Changed 17 years ago by
Damn, too bad. If you can get a new stacktrace I'll take another stab at it.
comment:11 follow-up: 12 Changed 17 years ago by
I don't think you picked up the patch properly. In gdb.2.txt, one of the stacktraces look like ;
182 #2 0x00002ae9412dc23b in QApplication::postEvent () 183 No symbol table info available. 184 #3 0x00002ae9402f7968 in MythObservable::dispatch (this=0x8edc50, event=@0x43881090) at mythobservable.cpp:45 185 listener = (struct QObject *) 0x914d20
which matches the pre-patched version of mythobservable.cpp since it class postEvent in line 45 ;
40 void MythObservable::dispatch(MythEvent &event) 41 { 42 QObject *listener = firstListener(); 43 while (listener) 44 { 45 QApplication::postEvent(listener, event.clone());
but the patched version has this ;
38 void MythObservable::dispatchNow(MythEvent &event) 39 { 40 QMutexLocker locked (&mutex); 41 QObject *listener = m_listeners.first(); 42 while (listener) 43 { 44 QApplication::sendEvent(listener, event.clone()); 45 listener = m_listeners.next();
so it looks like you're still running the old code. Can you check that you properly recompiled/reinstalled etc ?
comment:12 Changed 17 years ago by
Seems that when I was installing the patch I applied it to my backend machine instead of the frontend by accident. Testing the patched frontend now.
comment:13 Changed 17 years ago by
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
Duplicate of #2557
It's pretty much impossible to debug without a backtrace - unless you want to add additional debugging to the code and hope to trigger it that way. Please reopen when you get one.. Closing as worksforme until then.