> I was unable to reproduce this bug. How are you running it?
I'm sorry to hear that. Sometimes I'm unable to reproduce it myself.
Let's hope there aren't any obscure memory corrupting pointers! Here
are the commands I used:
~/root/bin$ ./bitcc --system ~/root -o fault fault.bitc
~/root/bin$ ./fault
Segmentation fault
~/root/bin$ ./bitcc --nostdlib -I ../include/ -o fault2 fault.bitc
../lib64/libbitc.a
~/root/bin$ ./fault2
Segmentation fault
However, things get strange. According to GDB, ios->f indeed appears
to be stdin until it gets to fread:
~/root/bin$ gdb ./fault
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f79a4add6e0 (LWP 8632)]
_IO_fread (buf=0x7fffacafcd40, size=1, count=1, fp=0x0) at iofread.c:43
43 _IO_acquire_lock (fp);
(gdb) print fp
$1 = (_IO_FILE *) 0x0
(gdb) up
#1 0x0000000000401467 in bitc_stdio_read_char (ios=0x602de0) at stdio.c:123
123 result = fread(&encoded[0], 1, 1, ios->f);
(gdb) print ios->f
$2 = (FILE *) 0x7f79a469b6a0
(gdb) print ios
$3 = (ty_bitc_stdioStream *) 0x602de0
(gdb) print stdin
$4 = (struct _IO_FILE *) 0x7f79a469b6a0
(gdb) print our_stdin
$5 = {f = 0x7f79a469b6a0}
(gdb) print &our_stdin
$6 = (ty_bitc_stdioStream *) 0x602de0
The backtrace is the same (without the thread part) when using --no-gc.
> I added a extra line (--emit 'Language') to the bitc --help output that
> shows how to specify the output language. About the library issue, are
> you talking about the --system option?
Yes, that's it. However, I didn't notice there a was man page - it's
all there. Doh.
Aleksi Nurmi
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
