You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just started testing sme-deu on larger corpus material and ran into a segfault, which is silently hidden when using apertium command... which is very bad for debugging use cause it seems like it finished succesfully.
==1498281== Memcheck, a memory error detector
==1498281== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1498281== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==1498281== Command: rtx-proc /home/flammie/github/apertium/apertium-sme-deu/sme-deu.rtx.bin
==1498281==
==1498281== Warning: client switching stacks? SP change: 0x1ffeffdc20 --> 0x1ffed8c898
==1498281== to suppress, use: --max-stackframe=2560904 or greater
==1498281== Invalid write of size 8
==1498281== at 0x11A729: RTXProcessor::filterParseGraph() (in /usr/bin/rtx-proc)
==1498281== by 0x11D7A4: RTXProcessor::processGLR(UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x11F453: RTXProcessor::process(_IO_FILE*, UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x10ED22: main (in /usr/bin/rtx-proc)
==1498281== Address 0x1ffed8c898 is on thread 1's stack
==1498281== in frame #0, created by RTXProcessor::filterParseGraph() (???:)
==1498281==
==1498281== Invalid write of size 8
==1498281== at 0x484D593: memset (vg_replace_strmem.c:1386)
==1498281== by 0x11A72D: RTXProcessor::filterParseGraph() (in /usr/bin/rtx-proc)
==1498281== by 0x11D7A4: RTXProcessor::processGLR(UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x11F453: RTXProcessor::process(_IO_FILE*, UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x10ED22: main (in /usr/bin/rtx-proc)
==1498281== Address 0x1ffed8c8a0 is on thread 1's stack
==1498281== in frame #1, created by RTXProcessor::filterParseGraph() (???:)
==1498281==
==1498281== Invalid read of size 8
==1498281== at 0x484D60D: memset (vg_replace_strmem.c:1386)
==1498281== by 0x11A72D: RTXProcessor::filterParseGraph() (in /usr/bin/rtx-proc)
==1498281== by 0x11D7A4: RTXProcessor::processGLR(UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x11F453: RTXProcessor::process(_IO_FILE*, UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x10ED22: main (in /usr/bin/rtx-proc)
==1498281== Address 0x1ffed8c898 is on thread 1's stack
==1498281== in frame #0, created by memset (vg_replace_strmem.c:1386)
==1498281==
==1498281== Invalid read of size 4
==1498281== at 0x119F74: RTXProcessor::filterParseGraph() (in /usr/bin/rtx-proc)
==1498281== by 0x11D7A4: RTXProcessor::processGLR(UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x11F453: RTXProcessor::process(_IO_FILE*, UFILE*) (in /usr/bin/rtx-proc)
==1498281== by 0x10ED22: main (in /usr/bin/rtx-proc)
==1498281== Address 0x1ffed8c8a0 is on thread 1's stack
==1498281== in frame #0, created by RTXProcessor::filterParseGraph() (???:)
==1498281==
==1498281== Warning: client switching stacks? SP change: 0x1ffed8c8a0 --> 0x1ffeffdce8
==1498281== to suppress, use: --max-stackframe=2561096 or greater
==1498281== Warning: client switching stacks? SP change: 0x1ffeffdc20 --> 0x1ffed8c898
==1498281== to suppress, use: --max-stackframe=2560904 or greater
==1498281== further instances of this message will not be shown.
==1498281== Invalid write of size 8
==1498281== at 0x11A729: RTXProcessor::filterParseGraph() (in /usr/bin/rtx-proc)
==1498281== Address 0x1ffd9e1e18 is on thread 1's stack
==1498281==
==1498281==
==1498281== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==1498281== Access not within mapped region at address 0x1FFD9E1E18
==1498281== at 0x11A729: RTXProcessor::filterParseGraph() (in /usr/bin/rtx-proc)
==1498281== If you believe this happened as a result of a stack
==1498281== overflow in your program's main thread (unlikely but
==1498281== possible), you can try to increase the size of the
==1498281== main thread stack using the --main-stacksize= flag.
==1498281== The main thread stack size used in this run was 8388608.
==1498281==
==1498281== HEAP SUMMARY:
==1498281== in use at exit: 12,215,494,831 bytes in 32,130,654 blocks
==1498281== total heap usage: 477,066,643 allocs, 444,935,989 frees, 135,790,349,643 bytes allocated
==1498281==
==1498281== LEAK SUMMARY:
==1498281== definitely lost: 0 bytes in 0 blocks
==1498281== indirectly lost: 0 bytes in 0 blocks
==1498281== possibly lost: 7,968 bytes in 15 blocks
==1498281== still reachable: 12,215,486,863 bytes in 32,130,639 blocks
==1498281== of which reachable via heuristic:
==1498281== newarray : 21,680 bytes in 1 blocks
==1498281== suppressed: 0 bytes in 0 blocks
==1498281== Rerun with --leak-check=full to see details of leaked memory
==1498281==
==1498281== For lists of detected and suppressed errors, rerun with: -s
==1498281== ERROR SUMMARY: 7707677 errors from 5 contexts (suppressed: 0 from 0)
I have not seen this kind of errors before so no idea of what's up...
The text was updated successfully, but these errors were encountered:
I just started testing sme-deu on larger corpus material and ran into a segfault, which is silently hidden when using
apertium
command... which is very bad for debugging use cause it seems like it finished succesfully.Zero output and the return code of apertium command is 0 (EXIT_SUCCESS)!
here's the output of previous step:
and a valgrind:
I have not seen this kind of errors before so no idea of what's up...
The text was updated successfully, but these errors were encountered: