[Perfparse-devel] Perfparse segfault on Solaris (fixed)

[Yves M. <yme...@li...>]

Answering to Darren Kemp...

I think I found the bug.
Read my_gethostname() at the beginning of config_file.c. Can you find the=
 malloc() ?
The bug is there: you read malloc(sizeof(MAXHOSTNAMELEN)) instead of
malloc(sizeof(char)*MAXHOSTNAMELEN)
Please change and recompile !

btw, Ben, this bug only happens on Solaris. Linux does not execute that c=
ode.

> Its interesting too, because if I move the config file out of the confi=
g
> dir, it exits normally as it should.
>
> Very strange. When I get some more free time I am going to try this
> compile on a different server.

Not so strange. Here is why:
When there is a buffer overflow somewhere, the program writes data in som=
e places it
should not. If you don't use Electric Fence, it usually writes data on th=
e same memory
page, which is forbidden, but does not generate a segmentation fault.
Writing data after the limit can overwrite other data. Then, those data m=
ean nothing.
And when fgets in our case, or other instruction (often printf) tries to =
do something,
it works with those corrupted data which make the program crash.

Now, the bug is not where it crashes. This is why you usually crash a pro=
gram somewhere
on a system, somewhere else on another system, never on other systems, an=
d in different
places with gdb or Electric Fence. Moreover, if you add printf() to debug=
, it will crash
again in a different place, or even not crash but corrupt the data !

The easy way that does not work all the time is to use gdb. The hard way =
that has always
worked 100% of the time for me is to use Electric Fence and either gdb wi=
th the dumped
core, or printf everywhere in the source code. printf("%s:%d\n", __FILE__=
,__LINE__);
It took me 10 minutes to find our bug when I started to use Electric Fenc=
e !

Now, if you move the config file somewhere else, it exits normally. This =
is because
my_gethostname() did not corrupt the data or the code to test if the file=
 exists and
exit if not. But even if it seemed to work, it was already buggy !

Well, thanks for reporting that bug that I consider as serious.
Please edit config_file.c yourself ASAP, or wait for 0.99.02 that Ben wil=
l probably
release before tomorrow.

Yves

>
> -dkk
>
>
> -----Original Message-----
> From: Yves Mettier [mailto:yme...@li...]
> Sent: Monday, July 19, 2004 2:37 PM
> To: Kemp, Darren
> Cc: be...@cl...
> Subject: RE: [Fwd: RE: [Perfparse-users] FW: Seg fualt]
>
> Ben, don't release 0.99.02 before I have a serious look on that one.
> I don't have the code here at home, but there is something strange...
>
> [...]
>
>> #4  0xff01142c in fgets () from /usr/lib/libc.so.1
>> #5  0xff142668 in conf_load (sFileName=3D0x0) at config_file.c:194
>> #6  0x0001124c in main (argc=3D2, argv=3D0xffbefd14) at perfparse.c:14=
9
> [...]
>> (gdb) p f
>> $2 =3D 0
>
> f should not be nul !!!!!
> There is a test before that makes the program quit if f is null !!! :)
> I'll have a look on that one tomorrow.
>
>
>
>> Dkk> 5.8 Generic_117350-04 sun4u sparc SUNW,Sun-Fire-480R
>
> 5.8 too for me :)
> But I cannot reproduce the bug :(
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -