View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0035639 | FPC | RTL | public | 2019-05-27 13:11 | 2020-11-24 06:27 |
| Reporter | Cyrax | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Linux x86_64 | OS | Arch | ||
| Product Version | 3.3.1 | ||||
| Summary | 0035639: [doublecommander] Getting SIGSEGV during normal string concat operation at program startup. | ||||
| Description | //#0 fpc_ansistr_concat(0x0, 0xdd92c0 'AddPoll ', 0x18cb6d0 '21', 0) at ../inc/astrings.inc:263 // local variables DESTS=0x0 S1='AddPoll ' S2='21' CP=0 S1LEN=8 S2LEN=281474976710658 SAME=3 S1CP=65001 S2CP=65001 DESTCP=65001 Somehow at this point, Length function gives string S2 wrong value. And further down the execution path, SetLength tries to allocate absurd amount memory for new string thus causing SIGSEGV to happen. | ||||
| Additional Information | Project Double Commander raised exception class 'External: SIGSEGV'. In file '../inc/astrings.inc' at line 779: PAnsiRec(Pointer(S)-AnsiFirstOff)^.CodePage:=cp; ---- #0 fpc_ansistr_setlength(0x0, 281474976710666, 65001) at ../inc/astrings.inc:779 0000001 fpc_ansistr_concat(0x0, 0xdd92c0 'AddPoll ', 0x18cb6d0 '21', 0) at ../inc/astrings.inc:280 0000002 ADDPOLL(21, 1, {Proc = {procedure (POINTER, TOBJECT)} 0x7fffffffdda0, Self = 0x1b252a8}, false) at platform/unix/upollthread.pas:67 0000003 TMONITOROBJECT__CREATE(0x1b252a8, 0x1) at platform/unix/linux/uudev.pas:604 0000004 INITIALIZE at platform/unix/linux/uudev.pas:533 0000005 TDRIVEWATCHER__INITIALIZE(0x10dc568, 21477072) at platform/udrivewatcher.pas:241 0000006 TFRMMAIN__FORMCREATE(0x1a09828, 0x1a09828) at fmain.pas:1043 0000007 TCUSTOMFORM__DOCREATE(0x1a09828) at include/customform.inc:939 0000008 TCUSTOMFORM__AFTERCONSTRUCTION(0x1a09828) at include/customform.inc:149 0000009 TFRMMAIN__AFTERCONSTRUCTION(0x1a09828) at fmain.pas:2646 0000010 TFRMMAIN__CREATE(0x1a09828, 0xffffffffffffffff, 0x1407518) at fmain.pas:2641 0000011 TAPPLICATION__CREATEFORM(0x1407518, 0xe6ed10, ) at include/application.inc:2241 0000012 main at doublecmd.lpr:195 --- #0 fpc_ansistr_setlength(0x0, 281474976710666, 65001) at ../inc/astrings.inc:779 // local variables of fpc_ansistr_setlength S=0x0 L=281474976710666 CP=65001 TEMP=0x7fffffffdc60 LENS=19 LENA=140737488346196 MOVELEN=1 --- //#0 fpc_ansistr_concat(0x0, 0xdd92c0 'AddPoll ', 0x18cb6d0 '21', 0) at ../inc/astrings.inc:263 // local variables DESTS=0x0 S1='AddPoll ' S2='21' CP=0 S1LEN=8 S2LEN=281474976710658 SAME=3 S1CP=65001 S2CP=65001 DESTCP=65001 --- procedure Print(const sMessage: String); begin WriteLn('PollThread: ', sMessage); end; procedure AddPoll(fd: cint; events: cshort; handler: TNotifyEvent; //0000001 ADDPOLL(21, 1, {Proc = {procedure (POINTER, TOBJECT)} 0x7fffffffdda0, Self = 0x1b252a8}, false) at platform/unix/upollthread.pas:67 CloseOnDestroy: Boolean); Var AString : String; begin EnterCriticalSection(Mutex); try if not Assigned(PollThread) then begin PollThread:= TPollThread.Create; end; PollThread.AddPoll(fd, events, handler, CloseOnDestroy); AString := IntToStr(fd); Print('AddPoll ' + AString); finally LeaveCriticalSection(Mutex); end; end; --- constructor TMonitorObject.Create; //0000002 TMONITOROBJECT__CREATE(0x1b252a8, 0x1) at platform/unix/linux/uudev.pas:604 var fd: cint; begin // Get the file descriptor (fd) for the monitor // This fd will get passed to poll() fd := udev_monitor_get_fd(udev_monitor); AddPoll(fd, POLLIN, Handler, False); Print('Begin monitoring'); end; | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | |||||
| FPCOldBugId | |||||
| FPCTarget | |||||
| Attached Files |
| ||||
|
|
May be related to this bug report : https://bugs.freepascal.org/view.php?id=34772 I'm using Sergei Gorelkin's patch from that bug report. EDIT : Host and target OS is x86_64-linux. |
|
|
Looks like that disabling subroutine inlining for system unit helped. No more SIGSEGV exceptions. EDIT : I was wrong, it didn't help. :-( |
|
|
I think that calling System.Str to convert integer to string somehow corrupts stack. There is a thread at the forum about this but I can't remember a link to it.#0 fpc_ansistr_setlength(0x0, 281474976710666, 65001) at ../inc/astrings.inc:779 0000001 fpc_ansistr_concat(0x0, 0xdd7a28 'AddPoll ', 0x1851ec0 '26', 0) at ../inc/astrings.inc:280 0000002 ADDPOLL(26, 1, {Proc = {procedure (POINTER, TOBJECT)} 0x7fffffffdd20, Self = 0x1bfb8c8}, false) at platform/unix/upollthread.pas:64 0000003 TMONITOROBJECT__CREATE(0x1bfb8c8, 0x1) at platform/unix/linux/uudev.pas:604 0000004 INITIALIZE at platform/unix/linux/uudev.pas:533 0000005 TDRIVEWATCHER__INITIALIZE(0x1102400, 27716328) at platform/udrivewatcher.pas:241 0000006 TFRMMAIN__FORMCREATE(0x1978248, 0x1978248) at fmain.pas:1095 0000007 TCUSTOMFORM__DOCREATE(0x1978248) at include/customform.inc:939 0000008 TCUSTOMFORM__AFTERCONSTRUCTION(0x1978248) at include/customform.inc:149 0000009 TFRMMAIN__AFTERCONSTRUCTION(0x1978248) at fmain.pas:2732 0000010 TFRMMAIN__CREATE(0x1978248, 0xffffffffffffffff, 0x144c9f8) at fmain.pas:2727 0000011 TAPPLICATION__CREATEFORM(0x144c9f8, 0xe48188, ) at include/application.inc:2241 0000012 main at doublecmd.lpr:196 |
|
|
platform/unix/upollthread.pas:64 Print('AddPoll ' + IntToStr(fd));
0000000000AFEB4D 488dbd10ffffff lea -0xf0(%rbp),%rdi
0000000000AFEB54 e8375e93ff callq 0x434990 <fpc_ansistr_decr_ref>
0000000000AFEB59 8b75f8 mov -0x8(%rbp),%esi
0000000000AFEB5C 488dbd08ffffff lea -0xf8(%rbp),%rdi
0000000000AFEB63 e8d8949aff callq 0x4a8040 <INTTOSTR>
0000000000AFEB68 488b9508ffffff mov -0xf8(%rbp),%rdx
0000000000AFEB6F b900000000 mov $0x0,%ecx
0000000000AFEB74 488d35ad8e2d00 lea 0x2d8ead(%rip),%rsi # 0xdd7a28 <.Ld2$strlab+24>
0000000000AFEB7B 488dbd10ffffff lea -0xf0(%rbp),%rdi
0000000000AFEB82 e8396093ff callq 0x434bc0 <fpc_ansistr_concat>
0000000000AFEB87 488bbd10ffffff mov -0xf0(%rbp),%rdi
0000000000AFEB8E e86dfeffff callq 0xafea00 <PRINT>
0000000000AFEB93 e8f81d94ff callq 0x440990 <fpc_popaddrstack>
|
|
|
function IntToStr(Value: Longint): string; begin System.Str(Value, result); end ; ../objpas/sysutils/sysstr.inc:852 00000000004A8054 488b5df0 mov -0x10(%rbp),%rbx 00000000004A8058 4889df mov %rbx,%rdi 00000000004A805B e830c9f8ff callq 0x434990 <fpc_ansistr_decr_ref> 00000000004A8060 4889da mov %rbx,%rdx 00000000004A8063 48637df8 movslq -0x8(%rbp),%rdi 00000000004A8067 b900000000 mov $0x0,%ecx 00000000004A806C 48c7c6ffffffff mov $0xffffffffffffffff,%rsi 00000000004A8073 e808e8f8ff callq 0x436880 <fpc_ansistr_sint> |
|
|
Using FPC trunk r42482. |
|
|
I have found the thread : https://forum.lazarus.freepascal.org/index.php/topic,45872.msg326710.html#msg326710 Also this bug triggers randomly, either on first execution of program or after several runs. |
|
|
It seems that cmem unit is the cause for this bug to happen. If I don't use it, there is no SIGSEGV happening after several runs under the GDB debugger or our own debugger (FPdebugger). |
|
|
Can you try compiling everything with -gv and then run the result under valgrind? (this will also implicitly use cmem) |
|
|
I compiled everything with -gv (FPC, Lazarus et al) and it is seems to be quite difficult produce this bug at repeated runs under valgrind. However I managed to get core dump file from gdb when it happened. Here is link to the binary and the core dump plus needed config file so it can be run as stand alone program : https://www.mediafire.com/file/trzdx1qwmjrm4k4/doublecmd.7z/file |
|
|
Here is valgrind output. No luck triggering at SIGSEGV error. |
|
|
The IndexByte warnings are false positives. The access(pathname) warning should not cause any issues in either (the syscall will just fail). The Python-related errors look bad though. |
|
|
I've seen random issues like this working with strings, it was due to the fact that using C type string functions there were no #0 (null) character at the start of an empty string thus leading to the assumption of a huge string when querying the length of it from random garbage in memory. using managed string functions on managed strings usually solves this but it isn't the cure. Even managed strings should also have a Null at the end even on empty strings. I use C type string functions on managed strings many times I need to ensure they have a null in them with empty strings. Just a thought./ |
|
|
> I've seen random issues like this working with strings, it was due to the fact that using C type string functions there were no #0 (null) character at the start of an empty string Please provide a test program that demonstrates this problem (in a separate bug report). |
|
|
Hmm, is address 0x7fffffffdda0 (in the addpoll line of the traceback) for a procedure healthy? |
|
|
I think this bug is caused by inlining. If I disable inlining from both System and SysUtils units, then SIGSEGV doesn't happen. x86_64-linux target is affected by this. i386-linux works even inlining enabled. --- Using now FPC trunk 3.3.1 r47484. |
|
|
Hmm, disabling inlining didn't help.#0 fpc_ansistr_setlength(0x0, 281474976710666, 65001) at ../inc/astrings.inc:778 0000001 fpc_ansistr_concat(0x0, 0xfc92e8 'AddPoll ', 0x1a50ad0 '26', 0) at ../inc/astrings.inc:280 0000002 ADDPOLL(26, 1, {Proc = {procedure (POINTER, TOBJECT)} 0x7fffffffdbe0, Self = 0x1ee9b48}, false) at platform/unix/upollthread.pas:69 0000003 TMONITOROBJECT__CREATE(0x1ee9b48, 0x1) at platform/unix/linux/uudev.pas:609 0000004 INITIALIZE at platform/unix/linux/uudev.pas:535 0000005 TDRIVEWATCHER__INITIALIZE(0x132a5d8, 24134832) at platform/udrivewatcher.pas:292 0000006 TFRMMAIN__FORMCREATE(0x1bce868, 0x1bce868) at fmain.pas:1132 0000007 TCUSTOMFORM__DOCREATE(0x1bce868) at include/customform.inc:923 0000008 TCUSTOMFORM__AFTERCONSTRUCTION(0x1bce868) at include/customform.inc:77 0000009 TFRMMAIN__AFTERCONSTRUCTION(0x1bce868) at fmain.pas:2793 0000010 TFRMMAIN__CREATE(0x1bce868, 0xffffffffffffffff, 0x1694f78) at fmain.pas:2788 0000011 TAPPLICATION__CREATEFORM(0x1694f78, 0x10764d0, ) at include/application.inc:2117 0000012 main at doublecmd.lpr:204 platform/unix/upollthread.pas:69 Print('AddPoll ' + IntToStr(fd)); 0000000000CAA2EE 488dbd10ffffff lea -0xf0(%rbp),%rdi 0000000000CAA2F5 e8367578ff call 0x431830 <fpc_ansistr_decr_ref> 0000000000CAA2FA 8b75f8 mov -0x8(%rbp),%esi 0000000000CAA2FD 488dbd08ffffff lea -0xf8(%rbp),%rdi 0000000000CAA304 e8176d86ff call 0x511020 <INTTOSTR> 0000000000CAA309 488b9508ffffff mov -0xf8(%rbp),%rdx 0000000000CAA310 b900000000 mov $0x0,%ecx 0000000000CAA315 488d35ccef3100 lea 0x31efcc(%rip),%rsi # 0xfc92e8 <.Ld2$strlab+24> 0000000000CAA31C 488dbd10ffffff lea -0xf0(%rbp),%rdi 0000000000CAA323 e8787778ff call 0x431aa0 <fpc_ansistr_concat> 0000000000CAA328 488bbd10ffffff mov -0xf0(%rbp),%rdi 0000000000CAA32F e8fcfdffff call 0xcaa130 <PRINT> 0000000000CAA334 e8e75479ff call 0x43f820 <fpc_popaddrstack> |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-05-27 13:11 | Cyrax | New Issue | |
| 2019-05-27 13:13 | Cyrax | Note Added: 0116431 | |
| 2019-05-27 13:14 | Cyrax | Note Edited: 0116431 | View Revisions |
| 2019-05-27 13:43 | Cyrax | Note Added: 0116432 | |
| 2019-05-27 13:44 | Cyrax | Note Edited: 0116432 | View Revisions |
| 2019-07-23 03:41 | Cyrax | Note Added: 0117344 | |
| 2019-07-23 03:50 | Cyrax | Note Added: 0117345 | |
| 2019-07-23 06:08 | Cyrax | Note Added: 0117346 | |
| 2019-07-23 06:10 | Cyrax | Note Added: 0117347 | |
| 2019-07-26 00:20 | Cyrax | Note Added: 0117400 | |
| 2019-07-27 07:40 | Cyrax | Note Added: 0117428 | |
| 2019-07-27 17:40 | Jonas Maebe | Note Added: 0117437 | |
| 2019-07-27 17:41 | Jonas Maebe | Note Edited: 0117437 | View Revisions |
| 2019-07-28 09:59 | Cyrax | Note Added: 0117451 | |
| 2019-07-28 12:51 | Cyrax | File Added: valgrind output.7z | |
| 2019-07-28 12:51 | Cyrax | Note Added: 0117454 | |
| 2019-07-28 14:08 | Jonas Maebe | Note Added: 0117457 | |
| 2019-07-28 16:21 | jamie philbrook | Note Added: 0117461 | |
| 2019-07-28 16:32 | Jonas Maebe | Note Added: 0117462 | |
| 2020-07-25 00:24 | Marco van de Voort | Note Added: 0124316 | |
| 2020-11-20 23:20 | Cyrax | Note Added: 0127077 | |
| 2020-11-24 06:27 | Cyrax | Note Added: 0127149 |
