#2340 SEGV on __GI_mempcpy (vg_replace_strmem.c:1537)
gnuplot 5.5 (last modified in 9.18) on centos linux 7.7.1908
information below from valgrind:
==12061== Invalid write of size 1
==12061== at 0x4C31D5D: __GI_mempcpy (vg_replace_strmem.c:1537)
==12061== by 0x6183FDB: _IO_default_xsputn (in /usr/lib64/libc-2.17.so)
==12061== by 0x6154032: vfprintf (in /usr/lib64/libc-2.17.so)
==12061== by 0x617843A: vsprintf (in /usr/lib64/libc-2.17.so)
==12061== by 0x615A5D6: sprintf (in /usr/lib64/libc-2.17.so)
==12061== by 0x75CA41: ENHX11_FLUSH (x11.trm:2054)
==12061== by 0x7A99DD: enhanced_recursion.constprop.132 (term.c:2438)
==12061== by 0x7AF43E: enhanced_recursion.constprop.133 (term.c:2264)
==12061== by 0x7A997C: enhanced_recursion.constprop.132 (term.c:2307)
==12061== by 0x7AA832: enhanced_recursion.constprop.132 (term.c:2264)
==12061== by 0x7E358B: ENHX11_put_text (x11.trm:2132)
==12061== by 0x802E6B: write_multiline (term.c:801)
==12061== Address 0x1fff004d93 is not stack'd, malloc'd or (recently) free'd
==12061==
==12061==
==12061== Process terminating with default action of signal 11 (SIGSEGV)
==12061== Access not within mapped region at address 0x1FFF004D93
==12061== at 0x4C31D5D: __GI_mempcpy (vg_replace_strmem.c:1537)
==12061== by 0x6183FDB: _IO_default_xsputn (in /usr/lib64/libc-2.17.so)
==12061== by 0x6154032: vfprintf (in /usr/lib64/libc-2.17.so)
==12061== by 0x617843A: vsprintf (in /usr/lib64/libc-2.17.so)
==12061== by 0x615A5D6: sprintf (in /usr/lib64/libc-2.17.so)
==12061== by 0x75CA41: ENHX11_FLUSH (x11.trm:2054)
==12061== by 0x7A99DD: enhanced_recursion.constprop.132 (term.c:2438)
==12061== by 0x7AF43E: enhanced_recursion.constprop.133 (term.c:2264)
==12061== by 0x7A997C: enhanced_recursion.constprop.132 (term.c:2307)
==12061== by 0x7AA832: enhanced_recursion.constprop.132 (term.c:2264)
==12061== by 0x7E358B: ENHX11_put_text (x11.trm:2132)
==12061== by 0x802E6B: write_multiline (term.c:801)
==12061== If you believe this happened as a result of a stack
==12061== overflow in your program's main thread (unlikely but
==12061== possible), you can try to increase the size of the
==12061== main thread stack using the --main-stacksize= flag.
==12061== The main thread stack size used in this run was 8388608.
==12061==
==12061== HEAP SUMMARY:
==12061== in use at exit: 191,836 bytes in 300 blocks
==12061== total heap usage: 925 allocs, 625 frees, 5,513,856 bytes allocated
==12061==
==12061== LEAK SUMMARY:
==12061== definitely lost: 0 bytes in 0 blocks
==12061== indirectly lost: 0 bytes in 0 blocks
==12061== possibly lost: 0 bytes in 0 blocks
==12061== still reachable: 191,836 bytes in 300 blocks
==12061== suppressed: 0 bytes in 0 blocks
==12061== Rerun with --leak-check=full to see details of leaked memory
==12061==
==12061== For lists of detected and suppressed errors, rerun with: -s
==12061== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Same as Bug #2331
sorry about this.sometime I can't get the information of the trigger line.Thus it would cause some duplication I can't figure out.