Crash, apparent memory corruption

[Pavel Roskin <proski@gnu.org>]

Hello!

I was trying to use current sparse from git on the current ndiswrapper.
The system is Fedora 8 x86_64 with all updates.  Just in case, the
kernel is from "wireless-2.6" repository, branch "everything".

When trying to use sparse on ndiswrapper, I found that sparse crashes on
a file called hal.c.  I made a version of the file after preprocessing
and put it here:

http://red-bean.com/proski/sparse/hal.c.bz2

The end of the output looks like this:

hal.c:19756:7: warning: label 'continue' already bound
hal.c:19756:7: warning: label 'break' already bound
hal.c:19756:125: warning: label 'continue' already bound
hal.c:19756:125: warning: label 'break' already bound
Segmentation fault (core dumped)

I guess sparse is already confused about something at this point.  The
full output to stderr is here:

http://red-bean.com/proski/sparse/sparse.stderr

And that's what gdb says (sparse was recompiled without optimization for
that):

Core was generated by `sparse hal.c'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000041aace in ptr_list_size (head=0x2b7ed86d29d0) at ptrlist.c:26
26                              nr += list->nr;
(gdb) p list
$1 = (struct ptr_list *) 0x5f7265776f6c000a
(gdb) p *list
Cannot access memory at address 0x5f7265776f6c000a
(gdb) where
#0  0x000000000041aace in ptr_list_size (head=0x2b7ed86d29d0) at ptrlist.c:26
#1  0x0000000000418004 in pseudo_list_size (list=0x2b7ed86d29d0) at lib.h:144
#2  0x0000000000417f40 in linearize_compound_statement (ep=0x2b7ed86b5520, stmt=0x2b7ed864e690) at linearize.c:1639
#3  0x000000000041810b in linearize_inlined_call (ep=0x2b7ed86b5520, stmt=0x2b7ed864e690) at linearize.c:1667
#4  0x0000000000418f67 in linearize_statement (ep=0x2b7ed86b5520, stmt=0x2b7ed864e690) at linearize.c:1957
#5  0x0000000000417bbf in linearize_expression (ep=0x2b7ed86b5520, expr=0x2b7ed85b9410) at linearize.c:1546
#6  0x0000000000418abf in linearize_statement (ep=0x2b7ed86b5520, stmt=0x2b7ed84fcdb0) at linearize.c:1868
#7  0x0000000000417ecc in linearize_compound_statement (ep=0x2b7ed86b5520, stmt=0x2b7ed84fcd60) at linearize.c:1629
#8  0x0000000000418f86 in linearize_statement (ep=0x2b7ed86b5520, stmt=0x2b7ed84fcd60) at linearize.c:1958
#9  0x0000000000419722 in linearize_fn (sym=0x2b7ed86073f0, base_type=0x2b7ed8605010) at linearize.c:2126
#10 0x000000000041988c in linearize_symbol (sym=0x2b7ed86073f0) at linearize.c:2195
#11 0x00000000004017cf in check_symbols (list=0x2b7ed85c3310) at sparse.c:266
#12 0x000000000040188f in main (argc=2, argv=0x7fffd3790d88) at sparse.c:284
(gdb)

Using valgrind, I don't see any relevant warnings before the place where
sparse crashes.

Pointer 0x5f7265776f6c000a looks fishy to me.  The initial bytes make
"lower_" if read in ASCII and consider that x86_64 is little endian.

Indeed, it must be coming from "lower_irql" used in the source.  If I
change that name, the pointer changes accordingly.  Moreover, 0x0a is
the symbol length, 10 characters, and it would change if I use a name of
a different length.

Any ideas how to debug it?

-- 
Regards,
Pavel Roskin