[sane-devel] problem in sanei_scsi.c (and hpusbscsi)

Rene Rebe rene.rebe@gmx.net
Sat, 13 Apr 2002 16:37:10 +0200 (CEST)


On: Sat, 13 Apr 2002 11:11:13 +0200,
    Henning Meier-Geinitz <henning@meier-geinitz.de> wrote:
> Hi,
> 
> On Sat, Apr 13, 2002 at 03:40:45AM +0200, Rene Rebe wrote:
> > After some more hours of debugging (+libefence) ... I have not found
> > the cause for this segmentation fault (but I did not had a glibc with
> > debugging symbols) - this was on a glibc-2.1.3. I decided to proceed
> > on a glibc-2.2.5 system to take advantages of the new malloc testing
> > facilities. I'm surprised that I can not reproduce thi crashes anymore
> > ... - Also not with libefence.
> 
> A typical heisenbug (goes away if you look too closely).

Jups ;-)

> Keep in mind that the bug may be at a completely different location
> somewhere earlier in the code. I even had bugs in the mustek backend
> that cause the next backend that was loaded by dll.c to segfault in
> some situations.
> 
> There may be a bug in glibc but I guess lots of other people would
> have noticed.

Currently I'm the only one getting this seg-fault (I'm one of the last
using a glibc-2.1.3 nowadays?).

First I was searching why a free () sometimes crashed. So obviously
memory got overwritten in another place. So I used libefence to track
the area where the memory is overwritten more accurately. There is
also not much between the mem allocatoin and the segfault. Only
malloc, fill scsi command, sanei_scsi_cmd to get the callib data ...

When I have too much time, I'll compile a glibc-2.1.3 with debugging
symbols .... (and so changing the bianry layout where the bug will not
shoe up ? ;-)

> Bye,
>   Henning

k33p h4ck1n6
  René

--  
René Rebe (Registered Linux user: #248718 <http://counter.li.org>)

eMail:    rene.rebe@gmx.net
          rene@rocklinux.org

Homepage: http://drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.