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 - To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
