Bug 31524

(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.