[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kudzu fix in tomorrow's rawhide too?



Program received signal SIGSEGV, Segmentation fault.
0x00bc8d63 in strdup () from /lib/libc.so.6
(gdb) bt
#0  0x00bc8d63 in strdup () from /lib/libc.so.6
#1  0x0805d6be in vbe_get_vbe_info () at vbe.c:193
#2 0x0805a8c5 in ddcProbe (probeClass=Variable "probeClass" is not available.
) at ddc.c:395
#3 0x080505bf in probeDevices (probeClass=CLASS_UNSPEC, probeBus=-9, probeFlags=1) at kudzu.c:806
#4  0x0804d186 in main (argc=Cannot access memory at address 0xffffffff
) at hwconf.c:938
#5  0x00b747e4 in __libc_start_main () from /lib/libc.so.6
#6  0x0804a4c1 in _start ()

OK, this implies we got back VBE2 data from the video card that
was valid (had a valid header), but the pointers to the actual
data inside the VBE2 data are bogus. That's hard to work around.

If you can break on it in gdb, what is it trying to strdup?

I'm not sure exactly what you are looking for but here is that line:
tmp = strdup(ret->oem_name.string); /* leak */

I poked around a bit, but my gdb skills are rather limited (for example I was trying to inspect the biosdata structure but it claimed it didn't exist in that context and I'm not sure what to do...I tried recompiling kudzu with -ggdb -O0 -g3 but that didn't help either).

A few lines up, there is the setting of ret->oem_name.string (the value it's trying to strdup):
        ret->oem_name.string = (char*) (f->base_addr() +  (biosdata->oem_name.seg << 4) +
                                        (biosdata->oem_name.ofs));
which I would guess is the problem (and asking gdb to print ret or ret->oem_name agrees that the
memory address for ret->oem_name.string was out of range):
(gdb) print ret->oem_name
$1 = {addr = {ofs = 12544, seg = 0}, string = 0x3100 <Address 0x3100 out of bounds>}

Here's another stack trace with glibc-debuginfo installed too:
Program received signal SIGSEGV, Segmentation fault.
0x0017ad63 in *__GI___strdup (s=0x3100 <Address 0x3100 out of bounds>) at strdup.c:42
42        size_t len = strlen (s) + 1;
(gdb) bt
#0  0x0017ad63 in *__GI___strdup (s=0x3100 <Address 0x3100 out of bounds>) at strdup.c:42
#1  0x0805db6b in vbe_get_vbe_info () at vbe.c:198
#2  0x0805ace5 in ddcProbe (probeClass=Variable "probeClass" is not available.) at ddc.c:395
#3  0x080509df in probeDevices (probeClass=CLASS_UNSPEC, probeBus=-9, probeFlags=1) at kudzu.c:806
#4  0x0804d5a6 in main (argc=Cannot access memory at address 0xffffffff) at hwconf.c:938
#5 0x001267e4 in __libc_start_main (main=0x804cd30 <main>, argc=1, ubp_av=0xbfc715e4, init=0x807c070 <__libc_csu_init>, fini=0x807c068 <__libc_csu_fini>, rtld_fini=0x2e4e40 <_dl_fini>, stack_end=0xbfc715dc) at libc-start.c:231
#6  0x0804a8e1 in _start ()

Want a core dump? Should I attach this to a bug somewhere or create a new one? The closest bug I could find was 177456 but I'm not sure if they are related.

Hope this helps! Thanks,

-Adam Batkin


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]