Re: [Plib-users] Crash in plibsl
Brought to you by:
sjbaker
From: Steve B. <sjb...@ai...> - 2000-08-19 22:33:51
|
Alexander Rawass wrote: > today I got this error while playing KobayashiMaru: > > bug: restF=160 > end-ptr=-152045057 w=176954717 > wAcc = 0 > Segmentation fault > > I grepped plib and found the lines which print these errors in > slMODinst.cxx Hmm - yes - that looks like some debug I'd left in there during development. 'end-ptr' means "The address of the end of the sound sample MINUS the address of the current replay pointer" - and it's value is pretty insanely negative - hence the error report. The program should probably do an 'abort' on that condition - but it's clearly not something that should ever happen. > Yes, I am playing MOD-files, just like it's shown in the easy-example > you support with plib, but I thought it would work since a week. > This error probably only happens some time, when there's an incorrect > MOD or so. Tell me more. Well, I've never had a report of a bug in the MOD player - and it's never died on any MOD file's I've ever seen...but that doesn't mean it's flawless. :-) I guess the first question is whether your application is corrupting something that *SUBSEQUENTLY* kills SL. The simplest way to prove that either way would be to play your MOD file using the sample program. Change 'mod_demo.cxx' so that instead of loading "Paravoka.mod", it loads your MOD file - and let me know if it still crashes. If it does crash - then we are certain the problem isn't in your application - and you can rest easy. Presumably we'd be looking at either a straight SL bug or a corrupted or illegal MOD file - and a problem that SL is not detecting that corruption and reporting it. (Well, it *is* reporting some kind of problem - but then crashing which isn't exactly friendly). We could go on to try to play the MOD file in another MOD player like FunkTrackerGOLD (which I use). If that reports a problem (or crashes or something) then we'll know it's a corrupt MOD file - and we'll have to chase down SL's error recovery routines to find out why it died after complaining instead of just exiting fatally but cleanly or aborting the music or something. Something as simple as changing the existing printf's into something more like "Corrupt MOD file - Bye-Bye" - followed by an 'exit' will suffice IMHO. If the 'mod_demo' crashes - but FunkTracker plays it flawlessly - then we have a genuine SL bug and you'll have to send me the MOD file so I can debug SL. The MOD player is horribly complex and I wouldn't wish that problem on anyone! On the other hand - If the example program DOESN'T crash while playing your MOD file then we must expect it's a bug in your application somewhere that's screwing up some memory that belongs to SL or something. It's not for *sure* that it's an application bug - it could be that SL has a data/timing dependant bug - but given it's previous 100% reliability record in literaly dozens of programs and with dozens of MOD files, I'd very much doubt that. If we end up at this point in the 'decision tree' then I'm betting on an application error...especially since yours is a fairly new program that probably doesn't have all of the kinks worked out of it yet. > I am currently using plib from cvs date 8. August 2000 SL hadn't changed in well over a year - so it shouldn't matter which version you have. It's by *far* the most stable PLIB component - and I'm pretty suprised to find a bug report. The *only* known problem comes in FlightGear when insanely large frequency and volume parameters are applied to a sound sample, that can cause some problems - but not in the music code - which is really very separate from the sound *sample* replayer stuff. So, work through the decision tree and tell us which branch you end up in! Try playing MOD in mod_demo / \ / \ Works Crashes / \ / \ Application Play MOD in Funktracker bug? / \ / \ Works Fails / \ Serious SL Bad MOD file, bug Another 'gut feeling' is that if it crashes intermittantly then it's MUCH more likely to be an application problem than an SL bug. Interactive applications do wildly different things each time they are run - but the job of the music player is *almost* the same every time (not quite because the timing changes from run to run - but *ALMOST* the same). Hence, intermittant bugs are most likely to be caused by the application in this case...not for *sure* but the odds are stacked that way. -- Steve Baker HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sourceforge.net http://tuxaqfh.sourceforge.net http://tuxkart.sourceforge.net http://prettypoly.sourceforge.net |