Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ SMAUG
➜ SMAUG coding
➜ MCCP and deflate
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Mon 29 Mar 2004 08:55 PM (UTC) |
| Message
| | We are using MCCP in our SWR, and I guess we missed something in the install. Running it through valgrind, I'm getting messages such as this:
Quote: ==15523== Conditional jump or move depends on uninitialised value(s)
==15523== at 0x4024C11C: (within /usr/lib/libz.so.1.2.1)
==15523== by 0x4024BC6E: (within /usr/lib/libz.so.1.2.1)
==15523== by 0x4024A585: deflate (in /usr/lib/libz.so.1.2.1)
==15523== by 0x80DC4C6: write_to_descriptor (comm.c:1832)
==15523== by 0x80DBF14: flush_buffer (comm.c:1637)
==15523== by 0x80DA2BC: game_loop (comm.c:841)
==15523== by 0x80D9378: main (comm.c:361)
I assume this means that we are not initializing something somewhere. The line that calls delfate in write_to_descriptor is if (d->out_compress->avail_out)
{
int status = deflate(d->out_compress, Z_SYNC_FLUSH);
if (status != Z_OK)
return FALSE;
}
We have d->out_comress initialized to NULL, but I know very little about MCCPs inner workings, and I couldn't find a man page on deflate. Anyone know what this is about? |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #1 on Tue 30 Mar 2004 12:20 AM (UTC) |
| Message
| | This resembles a problem I had when attempting to upgrade to Zlib 1.2, I notice the lib reported in your backtrace is the 1.2 version. I never figured out the problem and ended up having to downgrade back to the 1.1.4 package to solve it. | | Top |
|
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Reply #2 on Wed 31 Mar 2004 06:19 AM (UTC) |
| Message
| | Unfortunately I am on a hosted server, so I can't change the libraries my self. Maybe there is no way to correct this. |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Wed 31 Mar 2004 06:28 AM (UTC) |
| Message
| Have a look in zlib.h - that describes in some detail how to use the routines.
However to save you the trouble, here is the relevant portion ...
deflate compresses as much data as possible, and stops when the input
buffer becomes empty or the output buffer becomes full. It may introduce some
output latency (reading input without producing any output) except when
forced to flush.
The detailed semantics are as follows. deflate performs one or both of the
following actions:
- Compress more input starting at next_in and update next_in and avail_in
accordingly. If not all input can be processed (because there is not
enough room in the output buffer), next_in and avail_in are updated and
processing will resume at this point for the next call of deflate().
- Provide more output starting at next_out and update next_out and avail_out
accordingly. This action is forced if the parameter flush is non zero.
Forcing flush frequently degrades the compression ratio, so this parameter
should be set only when necessary (in interactive applications).
Some output may be provided even if flush is not set.
Before the call of deflate(), the application should ensure that at least
one of the actions is possible, by providing more input and/or consuming
more output, and updating avail_in or avail_out accordingly; avail_out
should never be zero before the call. The application can consume the
compressed output when it wants, for example when the output buffer is full
(avail_out == 0), or after each call of deflate(). If deflate returns Z_OK
and with zero avail_out, it must be called again after making room in the
output buffer because there might be more output pending.
If the parameter flush is set to Z_SYNC_FLUSH, all pending output is
flushed to the output buffer and the output is aligned on a byte boundary, so
that the decompressor can get all input data available so far. (In particular
avail_in is zero after the call if enough output space has been provided
before the call.) Flushing may degrade compression for some compression
algorithms and so it should be used only when necessary.
If flush is set to Z_FULL_FLUSH, all output is flushed as with
Z_SYNC_FLUSH, and the compression state is reset so that decompression can
restart from this point if previous compressed data has been damaged or if
random access is desired. Using Z_FULL_FLUSH too often can seriously degrade
the compression.
If deflate returns with avail_out == 0, this function must be called again
with the same value of the flush parameter and more output space (updated
avail_out), until the flush is complete (deflate returns with non-zero
avail_out).
If the parameter flush is set to Z_FINISH, pending input is processed,
pending output is flushed and deflate returns with Z_STREAM_END if there
was enough output space; if deflate returns with Z_OK, this function must be
called again with Z_FINISH and more output space (updated avail_out) but no
more input data, until it returns with Z_STREAM_END or an error. After
deflate has returned Z_STREAM_END, the only possible operations on the
stream are deflateReset or deflateEnd.
Z_FINISH can be used immediately after deflateInit if all the compression
is to be done in a single step. In this case, avail_out must be at least
0.1% larger than avail_in plus 12 bytes. If deflate does not return
Z_STREAM_END, then it must be called again as described above.
deflate() sets strm->adler to the adler32 checksum of all input read
so far (that is, total_in bytes).
deflate() may update data_type if it can make a good guess about
the input data type (Z_ASCII or Z_BINARY). In doubt, the data is considered
binary. This field is only for information purposes and does not affect
the compression algorithm in any manner.
deflate() returns Z_OK if some progress has been made (more input
processed or more output produced), Z_STREAM_END if all input has been
consumed and all output has been produced (only when flush is set to
Z_FINISH), Z_STREAM_ERROR if the stream state was inconsistent (for example
if next_in or next_out was NULL), Z_BUF_ERROR if no progress is possible
(for example avail_in or avail_out was zero).
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Reply #4 on Wed 31 Mar 2004 07:11 AM (UTC) |
| Message
| Ok, if I understand correctly, then the important part here is this: d->out_compress->avail_out =
COMPRESS_BUF_SIZE -
(d->out_compress->next_out -
d->out_compress_buf);
if (d->out_compress->avail_out)
{
int status = deflate(d->out_compress,
Z_SYNC_FLUSH);
if (status != Z_OK)
return FALSE;
}
This should be setting avail_out, but I assume its not, since I'm getting the error messages.
Quote: Before the call of deflate(), the application should ensure that at least
one of the actions is possible, by providing more input and/or consuming
more output, and updating avail_in or avail_out accordingly I beleive that the above code is doing what this is saying, but it must be doing it improperly.
Quote: In particular
avail_in is zero after the call if enough output space has been provided
before the call . I supposed that enouch space is not being provided then? What would one do to provide enough space, if this were indeed the problem? |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Wed 31 Mar 2004 07:20 AM (UTC) |
| Message
|
Quote:
We have d->out_comress initialized to NULL,
I assume you mean "d->out_compress" - this doesn't sound right. That is where the data goes.
If you have a look at the code for deflate it starts like this:
int ZEXPORT deflate (strm, flush)
z_streamp strm;
int flush;
{
int old_flush; /* value of flush param for previous deflate call */
deflate_state *s;
if (strm == Z_NULL || strm->state == Z_NULL ||
flush > Z_FINISH || flush < 0) {
return Z_STREAM_ERROR;
}
So, if you supply a null (Z_NULL) then it immediately returns an error.
The define for Z_NULL is:
#define Z_NULL 0 /* for initializing zalloc, zfree, opaque */
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Reply #6 on Wed 31 Mar 2004 07:23 AM (UTC) |
| Message
| | I just had the pointer initialized as NULL, which I guess is the same in this case as Z_NULL, but that was only in init_descriptor, and I only put that in after I noted these errors. I'm reading through the zlib now, so hopefully it will make some more sense. |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Reply #7 on Wed 31 Mar 2004 07:28 AM (UTC) |
| Message
|
Quote: The application must initialize zalloc, zfree and
opaque before calling the init function. This might do it. With a quick grep, zalloc and zfree are initialized to Z_NULL, and opaque is only initialized to NULL. This will be the first places that I check after I'm through with this read. |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Reply #8 on Wed 31 Mar 2004 08:26 AM (UTC) |
| Message
| These three are all initialized to Z_NULL, but still the errors. I'm not quite sure what to do from there, though I have played with s->total_in and s->total_out for some compression stats in the mud. I assume this is the same thing used by MUSHclient in the information section.
Still, I can't see much else that might not be initialized, unless avail_out is not being set to big enough, I'm sure. |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #9 on Wed 31 Mar 2004 01:17 PM (UTC) |
| Message
| | All of this is exactly what I was going through trying to figure out how to fix it. Which is why I eventually gave up and reverted back to the 1.1.4 package. The code wasn't changed so I fail to see why it would just stop working unless the zlib developers changed the API or something. Well... I shouldn't say it wasn't working, it was just leaking massive amounts of memory when called. | | Top |
|
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Reply #10 on Wed 31 Mar 2004 04:35 PM (UTC) |
| Message
| | Well, the host thing doesn't allow me to do this, but the MCCP is saving me such a large amount of bandwidth I would rather not give it up. So, it is preferable that I can find a solution to it. Is it actually leaking, or is it reporting that it might be? I'm not real clear on the messages from valgrind. |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #11 on Wed 31 Mar 2004 10:04 PM (UTC) |
| Message
| Why can't you use an earlier version? The MUD hosts let you put your source there don't they? And you compile it? Just use the zlib source and statically link it in.
As for MUSHclient it decompresses, not compresses as the server compresses and MUSHclient decompresses. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Reply #12 on Wed 31 Mar 2004 10:36 PM (UTC) |
| Message
| | Yeah,I was just refering to the use of total_in and total_out in the zstream structure. I never even though about using the 1.1.4 source, I'll try to find it, thanks. |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
26,294 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top