zlib & segmentation fault

[Darrin Smith]

I have written a small tape archive program to work around some of the
restrictions of my particular tape drive. The program has tested fine
except for the uncompressing of files. Without using compression
techniques, I have been able to succesfully store and retrieve a gig without
problems. I am also able to store data using compression without a hitch.
However, when I try to restore & uncompress the files I get a segmentation
fault after extracting most of the data.
I am using the high level zlib commands of gzopen,gzwrite,gzread, etc. As
best as I can tell, the fault occurs inside the zlib library at memset. I
know that I am f'ing something up somewhere. Additionaly, I originally was
using bzlib and got similar results (although much slower).

Here is the suspect routine that I currently have.

char zdecompress(char *fromfile, char *tofile)
{
int outstream;
gzFile *instream;
char buffer[BUFFERSIZE];
long read_size;

instream = (gzFile *) gzopen(fromfile,"rb");

outstream = open(tofile,O_WRONLY | O_CREAT | O_TRUNC);

while( read_size = gzread(instream,buffer,BUFFERSIZE) ){
if(read_size < 0)
return -1;
write(outstream,buffer,read_size);
}

gzclose(instream);
close(outstream);

return 0;
}

I have experimented with the BUFFERSIZE value ranging from 100000 to
5000000.

I would appreciate any suggestions or possible things to look for.

[Daniel Barron]

"Darrin Smith" <dar...@pentslc.com> did once decree:
[snip]
> gzFile *instream;

In my code this is not a pointer:
gzFile instream;

[snip]

> I would appreciate any suggestions or possible things to look for.

--
Daniel Barron - use [at jadeb.com] for personal replys.
(Visit http://dansguardian.org/ - True web content filtering for all)

[Rene Herman]

Darrin Smith wrote:

> gzFile *instream;
[...]

> instream = (gzFile *) gzopen(fromfile,"rb");

gzopen() returns a gzFile, not a gzFile*

Rene.

[Darrin Smith]

"Rene Herman" <rene....@mail.com> wrote in message
news:3B7317F8...@mail.com...

Thanks for the catch. I read in zlib.h that gzFile was a voidp and it stuck
in my memory. I changed my code, but still have the same situation. Since
both versions essentialy were voidp this did not cause any immediate
effects.

Let me through out another question. I am using the c++ allocation method
of new object[size] in my code. While zlib is using the c standard
malloc(). Could this be a problem? I am contemplating changing all of my
code to use malloc. Is this a waste of time? I am almost sure that my seg
fault comes at gzclose when memory is being released. Any comments?

[Nate Eldredge]

"Darrin Smith" <dar...@pentslc.com> writes:

This should not be a problem, AFAIK. `new' and `malloc' can coexist
perfectly well. You just have to be sure that memory obtained from
`new' is freed by `delete', and `malloc' by `free'. So unless zlib is
handing you allocated blocks and expecting you to free them (or vice
versa), this is not your problem.

Most likely, you have a bug elsewhere in your program. Crashes in
free and the like are usually due to overrunning buffers and similar
bugs.

There is no reason to switch all your code from `new' to `malloc'.

--

Nate Eldredge
neld...@hmc.edu

[Rene Herman]

Darrin Smith wrote:

> > gzopen() returns a gzFile, not a gzFile*
>

> Thanks for the catch. I read in zlib.h that gzFile was a voidp and it stuck
> in my memory. I changed my code, but still have the same situation. Since
> both versions essentialy were voidp this did not cause any immediate
> effects.

If a gzFile is a void* (a pointer) then a gzFile* is a void** (a pointer
to a pointer) which I wouldn't really call essentialy a voidp. However,
since you were only shipping the value to the other gz*() functions, I
guess that on reflection, no immediate effect *was* to be expected.

> Let me through out another question. I am using the c++ allocation method
> of new object[size] in my code. While zlib is using the c standard
> malloc(). Could this be a problem? I am contemplating changing all of my
> code to use malloc. Is this a waste of time?

I know precious little about C++ so I'm affraid I'm not the person to
ask. Seeing as how you did however, I would expect it to indeed be a
waste of time. I could imagine that one might need to be careful to pair
up new/delete and malloc/free in mixed C and C++ code but other than
that I'd expect no problems.

> I am almost sure that my seg fault comes at gzclose when memory is being
> released. Any comments?

Looking at your code again, you aren't checking *any* return values. My
first suggestion therefore would be to add some much needed error
handling. Is the gzopen() even succeeding? You didn't check. Then, if
you're not comfortable with a debugger, add a few debugging
printf's/cout's around the things that might fail to show which parts
did succeed before the SEGV (remember to flush stdout each time by
adding a \n/endl). This could at least confirm or deny that gzclose() is
the culprit.

Another thing I noticed is that you are placing your buffer on the stack
and are saying that you tried values ranging from 100K up to as much as
5M for it. That's a bit steep to say the least! My first suggestion
would be to place your buffer in BSS (declare it outside any function)
and even then to switch to a somewhat saner buffer value such as 4096
bytes. I don't expect you'll see much difference in throughput going
beyond that although you may ofcourse experiment with it once you have
this working. I don't expect it's going to change the SEGV though.

If after adding the error handling it still bombs out and after some
debugging has shown that it really is gzclose(), you may try ripping the
gz code out by replacing the gzopen/gzread/gzclose with open/read/close
and, if that works, by going to fopen/fread/fclose to further isolate
the problem.

I compiled your code here and it just worked, so I'm sort of expecting
that your trouble is elsewhere. If you somehow screwed up the memory
manager (perhaps by freeing something you didn't alloc or something)
errors might well show up in completely unrelated places so if you
continue to have trouble I believe you need to post a bit more of the
surrounding code. Better still, try to write a *full* program that uses
your zdecompress() and shows the same behaviour. Changes are good that
you won't be able to reproduce the problem, and selectively adding more
and more bits of your original program untill it *does* crash might be
all you need to indicate where the problem was.

Hope this helps.

Rene.