bogoutil segfaults

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> Clint & Matthias,
>
> Below I've trimmed the output a bit, so all that's left is the bogoutil
> invocation and the dump_file().
>
> At 08:35 AM 7/23/03, Clint Adams wrote:
>
>> Core was generated by `../../bogoutil -a 20020815 -s4,30 -d
>>./checks.1487.20030723T083159/t.dump.load.'.
>>Program terminated with signal 11, Segmentation fault.
> ..[snip]...
>> #2  0x0001179c in dump_file (db_file=0x1317e4f <Address 0x1317e4f out
>> of bounds>) at ../../bogofilter-0.14.0/src/bogoutil.c:178
>
>
>> Core was generated by `../../bogoutil -d
>>./checks.1567.20030723T083209/wordlist.db'.
>>Program terminated with signal 11, Segmentation fault.
> ..[snip]...
>> #2  0x0001179c in dump_file (db_file=0x131a35f <Address 0x131a35f out
>> of bounds>) at ../../bogofilter-0.14.0/src/bogoutil.c:178
>
> It's very strange that the first parameter to dump_file() is bad.

You're looking at RISC code, and RISCs as well as m68k tend to pass a
lot of data in registers, for they have plenty of them and they are
faster than pushing to or popping from the stack. So never mind function
arguments of any but the current frame. Sun DBX does the right thing,
refusing to print function parameters for optimized code.

If you want to know what happens, you'll need to single step
it. Unfortunately, you don't have a HP-PA RISC machine (and I have no
clues whether I can get my old Amiga, m68k, to run NetBSD and how long
that would take with just a slow serial connection; ages probably.)

I don't have time right now, and when I tried to provoke a crash, my
gcc-compiled SPARC code passes all tests both in 32- and 64-bit code and
exchanging -fast for -g made the problem go away.

So maybe this is a heisenbug. Dunno.

-- 
Matthias Andree