Thread: [Plib-users] Crash in plibsl
Brought to you by:
sjbaker
Menu
▾
▴
plib-users
|
From: Alexander R. <a_r...@in...> - 2000-08-19 20:26:21
|
Hi,
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
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.
I am currently using plib from cvs date 8. August 2000
Alex
--
Alexander Rawass
Email: ale...@us...
Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...
|
|
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
|
|
From: Alexander R. <a_r...@in...> - 2000-08-20 04:25:50
|
Hi,
Steve Baker wrote:
> 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.
This is the file:
alex@annika:/vast1/source/kobayashimaru > dir sounds/big*
-r--r--r-- 1 alex users 58596 Oct 15 1996
sounds/bigjapn2.mod
I copied the file to the examples/src/sl directory as Paravoka.mod, and
tried
it:
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl >
./mod_demo
Segmentation fault
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
./mod_demo
Segmentation fault
real 2m2.278s
user 0m0.070s
sys 0m0.000s
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
./mod_demo
Segmentation fault
real 2m2.286s
user 0m0.080s
sys 0m0.000s
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
./mod_demo
Segmentation fault
real 2m2.282s
user 0m0.050s
sys 0m0.030s
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl >
./mod_demo
Segmentation fault
Somehow, it crashes, but no debug printout this time.
> 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
Phew. Lucky me ;-)
> at either a straight SL
> bug or a corrupted or illegal MOD file -
I suspect an illegal MOD file - it was just lying around, never tested
it
before.
> and a problem that SL is not detecting that corruption and reporting
> it.
Probably.
> 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
Urks - I don't know if I've got some Tracker lying around.
> or something) then we'll know it's a corrupt MOD file - and we'll have
I can send it to you/ put it in my ftp-space, if you like.
> 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.
Aeh - no.
You should abort the playing of this mod, maybe try it from the
beginning
(if called as loopMusic()), but you shouldn't abort the hole program if
there's any chance that gameplay can continue without playing the MOD
(or without playing any sounds) or report an error somehow back to the
game that uses sl, but please no exit().
> 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!
I'll copy it to my ftp-space, directory plib before I send this mail.
> > 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.
Have you thought about playing MIDI-Files? (I know it's very different
in playing
from mods)
I personally would like that better, and I have many MIDI-files around.
> It's by *far* the most stable PLIB component - and I'm pretty suprised
> to find a bug report.
Shove me a virtual glass of champagne :-)
I didn't touch MODs since I dumped my Amiga, and I expect one can
probably
find more corrupt MODs with real bad sound in the net than good ones?
> So, work through the decision tree and tell us which branch you end up in!
>
> Try playing MOD in mod_demo
> / \
> / \
> Works Crashes
^^^^^^^
> 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
I proably didn't run that mission with that MOD for more that 2min
before,
so the error didn't occur
Alex
--
Alexander Rawass
Email: ale...@us...
Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...
|
|
From: Steve B. <sjb...@ai...> - 2000-08-20 06:03:31
|
Alexander Rawass wrote:
> alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
> ./mod_demo
>
> Segmentation fault
OK! So we can be sure it's not an application failure.
> Somehow, it crashes, but no debug printout this time.
Interesting.
> I suspect an illegal MOD file - it was just lying around, never tested
> it before.
OK - better email it to me (*NOT* to the list please).
> Urks - I don't know if I've got some Tracker lying around.
You should probably grab a copy of Funktracker or something - it's always
handy for simple things like speeding the music up or slowing it down.
> Aeh - no.
> You should abort the playing of this mod, maybe try it from the
> beginning
> (if called as loopMusic()), but you shouldn't abort the hole program if
> there's any chance that gameplay can continue without playing the MOD
> (or without playing any sounds) or report an error somehow back to the
> game that uses sl, but please no exit().
Well, that degree of error checking is expensive to implement - and you
wouldn't REALLY ever deliver a game with a corrupt MOD file - so I don't
think it's unreasonable to exit when you find a bad one.
> Have you thought about playing MIDI-Files? (I know it's very different
> in playing from mods)
> I personally would like that better, and I have many MIDI-files around.
Well, very few end-users have their MIDI set up done correctly...and even
when they do, you have no guarantee that their instrument setups are
compatible with the original artist's intentions. You might play a
subtle, gentle piano sonata - only to find that your end user has that
voice set up as "Trobone" or something! There is a standard for this
"General MIDI" - but the selection of instruments is miserable.
Altogether - MIDI is a poor choice.
I'm told there are tools to convert MIDI to MOD - but I have no idea
what they are.
> I didn't touch MODs since I dumped my Amiga, and I expect one can probably
> find more corrupt MODs with real bad sound in the net than good ones?
Not so far. Every MOD file up until now has played OK.
> I proably didn't run that mission with that MOD for more that 2min
> before, so the error didn't occur
OK. But the mod_demo test proves it's not application problems - so
we need to look at the MOD file and go from there.
--
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
|
|
From: Alexander R. <a_r...@in...> - 2000-08-24 17:57:51
|
Hi, Steve Baker wrote: > > OK! So we can be sure it's not an application failure. > > > I suspect an illegal MOD file - it was just lying around, never tested > > it before. > > OK - better email it to me (*NOT* to the list please). You may have overread it in my mail before: ftp://kobayashimaru.sourceforge.net/pub/kobayashimaru/plib/ File bigjapn2.mod Alex -- Alexander Rawass Email: ale...@us... Project Homepage: http://kobayashimaru.sourceforge.net ...but some day you'll be a STAR in somebody else's SKY... |
|
From: David B. <da...@fi...> - 2000-08-25 03:30:47
|
Hmmm, it seems to play just fine on my plib-1.2.0 install, if a bit on the LOUD side. All I did was copy bigjapn2.mod to examples/sl in plib_examples, rename it to "Paravoka.mod", and "./mod_demo". Alexander Rawass wrote: > > Hi, > > Steve Baker wrote: > > > > OK! So we can be sure it's not an application failure. > > > > > I suspect an illegal MOD file - it was just lying around, never tested > > > it before. > > > > OK - better email it to me (*NOT* to the list please). > > You may have overread it in my mail before: > > ftp://kobayashimaru.sourceforge.net/pub/kobayashimaru/plib/ > File bigjapn2.mod > > Alex |
|
From: Steve B. <sjb...@ai...> - 2000-08-25 04:56:29
|
David Bateman wrote:
>
> Hmmm, it seems to play just fine on my plib-1.2.0 install, if a bit on the
> LOUD side. All I did was copy bigjapn2.mod to examples/sl in plib_examples,
> rename it to "Paravoka.mod", and "./mod_demo".
Nope - it Seg Faulted on my machine...it looks like it did it when the music
ended and it was due to wrap-around an start playing for a second time.
Program received signal SIGSEGV, Segmentation fault.
_MOD_instHirevLoop (ihip=0x807df50) at slMODinst.cxx:129
129 int d = ( signed char ) ( *ihiPtr ^ 0x80 ) ;
(gdb) where
#0 _MOD_instHirevLoop (ihip=0x807df50) at slMODinst.cxx:129
#1 0x804d3c4 in _MOD_instLoop () at slMODinst.cxx:468
#2 0x804f073 in _MOD_playNote () at slMODnote.cxx:435
#3 0x804b2dc in MODfile::play_one (this=0x806f730, ppat=12)
at slMODfile.cxx:400
#4 0x804bb0f in MODfile::update (this=0x806f730) at slMODfile.cxx:523
#5 0x804a52f in slMODPlayer::low_read (this=0x806f6d8, nframes=1024,
dst=0x806e6b8 't' <repeats 12 times>, at slMODPlayer.cxx:41
#6 0x804a30d in slPlayer::read (this=0x806f6d8, nframes=1024,
dst=0x806e6b8 't' <repeats 12 times>, next_env=0) at slPlayer.cxx:62
#7 0x80494a2 in slScheduler::realUpdate (this=0x8053da0, dump_first=0)
at slScheduler.cxx:196
#8 0x8048d2f in main () at /usr/include/plib/sl.h:676
Also, I loaded it into FunkTrackerGOLD - it didn't complain *or* crash
but it *did* play the tune at about twice the normal speeed. That double
speed thing is *strange* - other tunes play at the same speed in
Funktracker and SL.
Does this mean that there is a bug in SL? Does it mean that the MOD file
is somehow 'broken'? I'm not sure. I was hoping for more concrete
evidence.
--
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X