generating core dump in linux

[Чебурашка]

Working under linux debian 12. I have this two softwares

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses
4.   SysUtils;
5. var
6.   n, d: Integer;
7. begin
8.   n := 20;
9.   d := 0;
10.   Writeln(Format('%f', [n/d]));
11. end.  
12.  

and

Code: C  [Select][+][-]

1. #include <stdio.h>
2. #include <stdlib.h>
3.  
4. int main(int argc, char** argv) {
5.  
6.     int n = 20;
7.     int d = 0;
8.    
9.     printf("%f", n/d);
10.    
11.     return 0;
12. }
13.  

I set ulimit -c unlimited to enable coredumps. Also I have kernel.core_pattern = core.

When I exec the pascal one I get no core and this message

Code: Bash  [Select][+][-]

1. An unhandled exception occurred at $0000000000401105:
2. EDivByZero: Division by zero
3.   $0000000000401105  main,  line 10 of project1.lpr
4.  

When I exec the C one I get the core and the following message

Code: Bash  [Select][+][-]

1. Floating point exception (core dumped)
2.  

Is it possible to obtain the coredump also in pascal? I need to debug a much bigger fpc application that crashes randomly.

[Darie]

What about infinite recursion?

[Red_prig]

try it https://wiki.freepascal.org/SetExceptionMask

[Чебурашка]

try it https://wiki.freepascal.org/SetExceptionMask

Thanks.

But if the exception is another (this program with a division by zero was just an example), let's say an access violation (SIGSEGV) the same problem arises, that is in C i get the core dumps, in fpc I don't.

Is there a compilation switch or directive to change this?

[Red_prig]

I think not, since core dump is a system call and as I understand it, Pascal does not use it when crashing, you can probably try to override this behavior

[MarkMLl]

I think not, since core dump is a system call and as I understand it, Pascal does not use it when crashing, you can probably try to override this behavior

...in which case looking for discussions relating to a custom global exception handler might be useful.

MarkMLl

[Чебурашка]

I think not, since core dump is a system call and as I understand it, Pascal does not use it when crashing, you can probably try to override this behavior

...in which case looking for discussions relating to a custom global exception handler might be useful.

MarkMLl

I don't find a way to disable the exception handling, like in the simple program above, instead of trapping anything, it should simply crash.

[Thaddy]

If you run your program under GDB you can have a core dump. I have to look up the options, long time since I used it.
[edit] This is chatGPT, but is a correct answer, it is close to how I remember it:

Code: Text  [Select][+][-]

1. Certainly! When debugging a program using GDB (GNU Debugger) on Linux, you can generate and analyze a core dump. Here’s how you can do it:
2.  
3. Enable Core Dumps:
4. First, check the maximum core dump size using:
5. ulimit -c
6.  
7. If the result is zero (meaning no core dump will be produced), set the limit to the maximum:
8. ulimit -c unlimited
9.  
10. Now, core dumps will be generated and placed in the location specified by /proc/sys/kernel/core_pattern.
11. Generating a Core Dump:
12. When your program crashes, it generates a core dump file (usually named core.pid, where pid is the process ID).
13. You can use the generate-core-file command within GDB to create a core dump of a running process:
14. gdb -p <pid>
15. (gdb) generate-core-file <output_file>
16.  
17. Analyzing the Core Dump:
18. Load the core dump file along with the binary (executable) using GDB:
19. gdb <executable_path> <coredump_file_path>
20.  
21. For example:
22. gdb ./my_program core.pid
23.  
24. Once inside the GDB prompt, you can use various commands:
25. bt (backtrace): Shows the stack trace at the time of the crash.
26. info locals: Displays values of local variables.
27. info registers: Shows values of CPU registers.
28. frame X: Changes to stack frame X.
29. up and down: Navigate within the call stack.
30. Remember that when using the core file, you don’t need to pass arguments; GDB already captures the state of the program during the crash. Happy debugging! &#128030;&#128269;123

Don't forget to set ulimit -c 0 after debugging.

[MarkMLl]

ulimit -c unlimited
 
Now, core dumps will be generated and placed in the location specified by /proc/sys/kernel/core_pattern.

He's already said that he's done this, and that the problem is peculiar to an FPC (apparently, FPC + Lazarus) program.

I'm pretty sure I used to set global exception handlers on Delphi programs which were effective and have set handlers on FPC threads to good effect, but don't know whether I've set an ultimate handler for an FPC/Lazarus app.

MarkMLl

[Thaddy]

Well, set the global exception handlers to nil?
That would be ExceptClsProc := nil; ExceptObjProc := nil; and ExceptProc := nil;
This must be done after the sysutils unit is loaded, because that will set these three. You have to unset them later than sysutils is loaded. (That is IF you use sysutils. Either direct or indirect)

[Чебурашка]

Well, set the global exception handlers to nil?
That would be ExceptClsProc := nil; ExceptObjProc := nil; and ExceptProc := nil;
This must be done after the sysutils unit is loaded, because that will set these three. You have to unset them later than sysutils is loaded. (That is IF you use sysutils. Either direct or indirect)

Thaddy rules.

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses
4.   SysUtils;
5. var
6.   n, d: Integer;
7.   r:Double;
8.  
9.   Procedure AExceptClsProc(Obj : TObject; Addr : CodePointer; FrameCount:Longint; Frame: PCodePointer);
10.   begin
11.     raise Exception.Create('AExceptClsProc');
12.   end;
13.   Procedure AExceptObjProc(Obj : TObject; Addr : CodePointer; FrameCount:Longint; Frame: PCodePointer);
14.   begin
15.     raise Exception.Create('AExceptObjProc');
16.   end;
17.   Procedure AExceptProc(Obj : TObject; Addr : CodePointer; FrameCount:Longint; Frame: PCodePointer);
18.   begin
19.     raise Exception.Create('AExceptProc');
20.   end;
21.  
22. begin
23.   SysUtils.Now; // Forcing SysUtils to be accessed (Thanks to Thaddy)
24.  
25.   ExceptClsProc := @AExceptClsProc;
26.   ExceptObjProc := @AExceptObjProc;
27.   ExceptProc := @AExceptProc;
28.  
29.   n := 20;
30.   d := 0;
31.   r := n/d;
32. end.
33.  

Result:

Code: Bash  [Select][+][-]

1. [13:42:02] mep@mep-development:~/tmp/2024-03-07-coredump$ ./project1
2. Segmentation fault (core dumped)
3.  

For info setting the three handlers to nil in the program above doesn't solve the problem, as executions sticks to the Runtime error messages.

Now I need to see what the coredump contains...

[MarkMLl]

Well, set the global exception handlers to nil?
That would be ExceptClsProc := nil; ExceptObjProc := nil; and ExceptProc := nil;
This must be done after the sysutils unit is loaded, because that will set these three. You have to unset them later than sysutils is loaded. (That is IF you use sysutils. Either direct or indirect)

Thaddy rules.

Looks about right. However I think the important thing is going to be the import order in the uses statement, since sysutils isn't load-on-demand your sysutils.Now() won't have any useful effect.

MarkMLl

[Чебурашка]

Now I need to see what the coredump contains...

Setting ExceptProc to nil doesn't work.
Setting to custom and doing nothing inside doesn't work.
Setting to custom and raising exception generates a segmentation fault (core dumped), but it is not because to the original exception, but is because stack runs out (infinite recursion like someone said before).

[MarkMLl]

Setting ExceptProc to nil doesn't work.
Setting to custom and doing nothing inside doesn't work.
Setting to custom and raising exception generates a segmentation fault (core dumped), but it is not because to the original exception, but is because stack runs out (infinite recursion like someone said before).

Yes, but we were assuming that you noticed Red_prig's suggestion that generating a coredump required a system call.

MarkMLl

[Чебурашка]

Yes, but we were assuming that you noticed Red_prig's suggestion that generating a coredump required a system call.

Ops sorry, thank you