Kudzu fix in tomorrow's rawhide too?

[Adam Batkin]

>> 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