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
|