> Am 13.06.2025 um 00:14 schrieb Paul Eggert <egg...@cs.ucla.edu>: > > On 2025-06-12 03:29, Peter Dyballa wrote: >> (gdb) p base >> $2 = 0x0 > > That's obviously wrong; 'base' should not be a null pointer. Can you track > down why it is a null pointer?
I think I am close to the cause (two sessions): Breakpoint 1 at 0x7e40: file context.c, line 246. Breakpoint 2 at 0x7ff4: file context.c, line 284. Breakpoint 3 at 0x84c0: file context.c, line 379. Breakpoint 4 at 0x8574: file context.c, line 395. Breakpoint 5 at 0x8664: file context.c, line 414. Reading symbols for shared libraries ...................+ done --- Portfile-graphite2-312 2025-06-09 15:48:08.000000000 +0200 +++ Portfile-graphite2 2025-06-09 15:48:08.000000000 +0200 @@ -27,14 +18,23 @@ Breakpoint 3, pr_unidiff_hunk (hunk=0x4014d0) at context.c:379 => print_1_line (nullptr, line); step -> print_1_line (line_flag=0x0, line=0x40137c) at util.c:989 step -> print_1_line_nl (line_flag=0x0, line=0x40137c, skip_nl=false) at util.c:1001 (gdb) p line $1 = (const char * const *) 0x40137c (gdb) p *line $2 = 0x0 (gdb) p line[0] $3 = 0x0 (gdb) p line[1] $4 = 0x18015ef "distname", ' ' <repeats 12 times>, "${name}-${version}\nextract.suffix .tgz\n\ncompiler.cxx_standard \\\n", ' ' <repeats 20 times>, "2011\n\nset py_ver 3.12\nset py_ver_nodot [string map {. {}} ${py_ver}]\n\ntest.run "... (gdb) p line[2] $5 = 0x1801616 "extract.suffix .tgz\n\ncompiler.cxx_standard \\\n", ' ' <repeats 20 times>, "2011\n\nset py_ver 3.12\nset py_ver_nodot [string map {. {}} ${py_ver}]\n\ntest.run", ' ' <repeats 12 times>, "yes\n#test.env", ' ' <repeats 12 times>, "ARG"... ---------------------------------------------------------------------------------------- --- Portfile-graphite2-312 2025-06-09 15:48:08.000000000 +0200 +++ Portfile-graphite2 2025-06-09 15:48:08.000000000 +0200 @@ -27,14 +18,23 @@ Breakpoint 1, pr_unidiff_hunk (hunk=0x4014d0) at context.c:369 (gdb) p last0 $1 = 9 (gdb) p last1 $2 = 9 (gdb) p i $3 = -4 (gdb) p j $4 = -13 (gdb) n (gdb) p next->line0 $5 = -1 Breakpoint 4, pr_unidiff_hunk (hunk=0x4014d0) at context.c:379 (gdb) p *out $8 = { _p = 0xc2001 "@ -27,14 +18,23 @@\ne2\t2025-06-09 15:48:08.000000000 +0200\n200\n", _r = 0, _w = -1, _flags = 2185, _file = 1, _bf = { _base = 0xc2000 " @ -27,14 +18,23 @@\ne2\t2025-06-09 15:48:08.000000000 +0200\n200\n", _size = 131072 }, _lbfsize = -131072, _cookie = 0xa0001bec, _close = 0x90015978 <__sclose>, _read = 0x9001ad80 <__sread>, _seek = 0x9001a970 <__sseek>, _write = 0x90015968 <__swrite>, _ub = { _base = 0x0, _size = 0 }, _extra = 0xa0001d58, _ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = { _base = 0x0, _size = 0 }, _blksize = 131072, _offset = 0 } A while loop starts on line #369, and then gdb steps through all lines, reaching 395 print_1_line_nl (nullptr, line, true); This "nullptr" is then passed forward to output_1_line() with base=0x0, to which fwrite() would write. Wouldn't it make more sense to use "out" instead of "nullptr"? Tomorrow I'll check what my more up-to-date Macs are doing. -- Greetings Pete To most people solutions mean finding the answers. But to chemists solutions are things that are still all mixed up.