Re: [opendemo-devel] qvm playback with compressed files

[Conor D. <co...@ma...>]

I think I've found abother bug in the qvm compiler. If you use ~var, where
var is a variable (or an expression that contains a variable) and not a
compile-time constant, you get funky values returned. I'm not sure if this
could cause the results you got, but zlib does use ~ with variables which
could cause problems.

I also modified the filebuf to read more data at once. Before, it would call
gzread for only a few characters at a time (usually just 1), because the
membuffer never grew to more than a dozen bytes if even that. Since each
gzread triggers about 5 inflate functions each call, this was really bogging
things down.

There's also an extensive function tracing system that logs most of the
important function calls (while slowing everything down to 2 fps). Helpful
for tracking qvm crashes (and how I found the filebuf problem).

I'll commit all the fixes tomorrow; I'm too tired right now.

-Conor

----- Original Message -----
From: "Dr. Uwe Girlich" <Uwe...@ph...>
To: "OpenDemo Development List" <ope...@li...>
Sent: Sunday, January 13, 2002 1:55 PM
Subject: [opendemo-devel] qvm playback with compressed files


> Hello!
>
> I just analysed the crashing behaviour of the QVM code on playback of
> compressed files. It is really strange. The attached patch file adds a
mini
> trace to the first call of fbReadChar, which get the character '<', as we
all
> would expect. But the calling function xmlParseText get another return
value.
>
> Loading vm file vm/qagame.qvm.
> VM file qagame compiled to 1493476 bytes of code
> qagame loaded in 19045056 bytes on the hunk
> fbReadChar(0) = '<' = 60
> xmlParseText: character = 'h' = 104
> End of recording
> Received signal 11, exiting...
> Shutdown tty console
>
> Sooner or or later this results in XML problems and the playback stops
> (output: "End of recording"). Then somehow (not really important just now)
> the program crashs totally with a SIGSEGV (segmantation violation).
>
> So the main problem is why the print of the character before the return
> statement of fbReadChar() was '<' but the calling function get another
value
> back. I have no idea, how this could occur, especially I don't see the
> connection with the zlib code.
>
> Bye, Uwe
>