After automatic update in Linux SUSE Enterprise 15 from gdb 12.1-150400.15.9.1-xf86_64 to 13.2-150400.15.14.1-xf86_64 my program stops with the message gdb encountered an internal error: Press "OK" to continue debugging. This may not be safe. Press "Stop" to end the debugging session. If I press "Continue" I get the message While executing the command: "TGDBMIDebuggerInstruction: "ptype Shortstring", [ifRequiresMemLimit]" gdb reported: "&"A fatal error internal to GDB has been detected, further\ndebugging is not possible. GDB will now terminate.\n\n" &"This is a bug, please report it."" The I get the message Debuggerfehler Der Debugger ist abgestürzt mit Status Speichern Sie Ihre Arbeit jetzt! Drücken Sie "Stop" und hoffen auf einen Fix für diesen Fehler. The gdb process is no longer running. gdb -v reports Version 13.2, but I this version-number in not choosable.
(In reply to Reinhard Buchholz from comment #0) Hi. Thank you for the bug report. > gdb encountered an internal error: Press "OK" to continue debugging. This > may not be safe. Press "Stop" to end the debugging session. Unfortunately this isn't enough information to know what's gone wrong. Could you possibly get a trace of the MI commands sent to gdb, and the full output from gdb? Maybe that would help. It might at least show where the internal error occurs.
Created attachment 15429 [details] logfile I get the logfile, when I call lazarus by lazarus --debug-log=LOG_FILE --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_ERRORS
Thanks for the log. I see this: >> TCmdLineDebugger.SendCmdLn "-gdb-set language pascal" ... >> TCmdLineDebugger.SendCmdLn "ptype Shortstring" << TCmdLineDebugger.ReadLn "&"ptype Shortstring\n"" << TCmdLineDebugger.ReadLn "~"type = ShortString = record \n"" << TCmdLineDebugger.ReadLn "~" length : BYTE;\n"" << TCmdLineDebugger.ReadLn "&"\n\n"" << TCmdLineDebugger.ReadLn "&"Fatal signal: "" << TCmdLineDebugger.ReadLn "&"Segmentation fault"" This output is clearly truncated and definitely a gdb bug. I suspect it could be reproduced with just the executable. If it's not too large, and if it's allowable, could you attach it? Could you say what Pascal compiler you are using? I wonder if maybe a test case with just the Shortstring type would be possible to write -- we'll want a test case for the patch anyway.
Created attachment 15434 [details] LOG_FILE.standalone The compiler is fpc 3.2.2 within lazarus 2.3.0. If I start the compiled program standalone I don't see any errors. The program works without any failure. I've attached the LOG_FILE.standalone.
I think, the logfile is truncated, becaus it is too big. I've put the complete logfile in dropbox: https://www.dropbox.com/scl/fi/raripqu9td0rytibh2cif/LOG_FILE?rlkey=r44ltlowsk1qv8ak68bxj8drn&dl=0 Lines 1 to 3088 are produced, when I start Lazarus by lazarus --debug-log=LOG_FILE --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_ERRORS lines 3089 to 4574, when I compile and run my program, the rest is when I close Lazarus
Created attachment 15435 [details] the part of the LOGFILE, when I rund my program I've extracted the part of the logfile, which is produced, when I start my program till it crashes
The original log file was fine -- it showed the problem. When I said "This output is clearly truncated" what I meant is that gdb crashed in the middle of printing a type. The next step here is to try to get a reproducer so we can debug the problem (and write a test). Since gdb is crashing during "ptype Shortstring", perhaps just the definition of that type would be enough. Or, a copy of your executable, if you can do that.
I've created a rudimentary "empty" program. gdb crashes, when I invole it in Lazarus by single-stepping. I've uploaded it to dropbox: https://www.dropbox.com/scl/fo/fd60j78485cb1p13ekots/h?rlkey=215mmm1osg6bb09z3ws9v8s55&dl=0
Thanks. I can reproduce in MI mode but not CLI mode, so that's interesting.
pager_file::puts allows NULL but the MI implementation does not.
It is just strange that the error did not appear in version 12.1.
(In reply to Reinhard Buchholz from comment #11) > It is just strange that the error did not appear in version 12.1. Looks like the printf/pager refactoring removed a null check that used to occur in fputs_maybe_filtered.
https://sourceware.org/pipermail/gdb-patches/2024-March/207606.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=edada1692cc4558138756eea99532d83b7b894e0 commit edada1692cc4558138756eea99532d83b7b894e0 Author: Tom Tromey <tom@tromey.com> Date: Wed Mar 27 10:34:46 2024 -0600 Make pascal_language::print_type handle varstring==nullptr PR gdb/31524 points out a crash when pascal_language::print_type is called with varstring==nullptr. This crash is a regression arising from the printf/pager rewrite -- that indirectly removed a NULL check from gdb's "puts". This patch instead fixes the problem by adding a check to print_type. Passing nullptr here seems to be expected in other places (e.g., there is a call to type_print like this in expprint.c), and other implementations of this method (or related helpers) explicitly check for NULL. I didn't write a test case for this because it seemed like overkill for a Pascal bug that only occurs with -i=mi. However, if you want one, let me know and I will do it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524 Approved-By: John Baldwin <jhb@FreeBSD.org>
Fixed.