> Am 13.06.2025 um 00:14 schrieb Paul Eggert <[email protected]>:
>
> 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.
