On Mon, Oct 15, 2007 at 06:29:05PM +0100, Francis Tyers wrote:
>
> $ strace apertium-preprocess-transfer apertium-en-ca.trules-en-ca.xml
> trules-en-ca.bin
I hope this is good too:
Core was generated by `apertium-preprocess-transfer
apertium-en-ca.trules-en-ca.xml trules-en-ca.bin'.
Program terminated with signal 11, Segmentation fault.
#0 ~ApertiumRE (this=0x7fff00000000) at apertium_re.cc:17
17 if(!empty)
(gdb) bt
#0 ~ApertiumRE (this=0x7fff00000000) at apertium_re.cc:17
#1 0x00002ad2c9d9e594 in TransferData::writeRegexps (
this=<value optimized out>, output=0xb2cb20) at transfer_data.cc:185
#2 0x00002ad2c9d9e6e0 in TransferData::write (this=0x7fffe0fa6918,
output=0xb2cb20) at transfer_data.cc:142
#3 0x00002ad2c9da560d in TRXReader::write (this=0x7fffe0fa68d0,
[EMAIL PROTECTED]) at trx_reader.cc:328
#4 0x0000000000400f4f in main (argc=<value optimized out>,
argv=0x7fffe0fa6c28) at transferpp.cc:40
(gdb) p empty
Cannot access memory at address 0x7fff00000000
(gdb) p &empty
$1 = (bool *) 0x7fff00000000
That value looks very strange to me, and at first sight looks like
either a gcc or binutils bug.
If I rebuild it with -O0, it doesn't segfault, build with -O3 it does.
PS: configure adds -O3 to your CFLAGS, even if you use
DEB_BUILD_OPTIONS=noopt, and you don't get a -g.
Could you please fix that in a next version?
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
