Re: port-sparc64/58936 (Building lang/swi-prolog-lite on NetBSD 10.1/sparc64 crashes the machine)

["Martin Husemann via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-sparc64/58936; it has been noted by GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-sparc64/58936 (Building lang/swi-prolog-lite on NetBSD
 10.1/sparc64 crashes the machine)
Date: Sat, 28 Dec 2024 14:43:41 +0100

 I could reproduce it (thanks Alexander for off-list help with that):
 
 [ 76%] Built target archive
 [ 76%] Generating SWI-Prolog-8.0.2.tex
 [ 76%] Generating intro.tex
 [ 76%] Generating overview.tex
 [ 76%] Generating builtin.tex
 [ 76%] Generating module.tex
 [ 76%] Generating foreign.tex
 [ 76%] Generating runtime.tex
 [ 76%] Generating hack.tex
 [ 76%] Generating summary.tex
 [ 76%] Generating xpce.tex
 [ 77%] Generating glossary.tex
 [ 77%] Generating ide.tex
 [ 77%] Generating license.tex
 [ 77%] Generating threads.tex
 [ 78%] Generating engines.tex
 [ 78%] Generating profile.tex
 [ 78%] Generating attvar.tex
 [ 78%] Generating chr.tex
 [ 78%] Generating xref.tex
 [ 78%] Generating bit64.tex
 [ 78%] Generating dialect.tex
 [ 78%] Generating extensions.tex
 [ 78%] Generating tabling.tex
 [ 78%] Generating lib/clpfdlib.tex
 
 
 this tries to dump core:
 proc_getauxv(pid 21737 cmd swipl) - ps_envstr 0x697220616e737765  nenvstr 1920154122  auxv 0x69722065020d47bd
 
 with obviously bogus ps_nenvstr, so we calculate a auxv vector way out of
 bounds.
 
 Due to bugs in the sparc64 kernel the kernel crashes with:
 
 
 [ 2338.2400852] panic: fault type 104 for invalid va 69722065020d4e78
 [ 2338.3200858] cpu1: Begin traceback...
 [ 2338.3600860] cpu1: End traceback...
 [ 2338.4000864] Frame pointer is at 0x2526e6551
 [ 2338.4500869] Call traceback:
 [ 2338.4900872]  netbsd:cpu_reboot+0x260(1cc46d8, 105a96140, ff0f0000000001, 0, 1c6f000, 1cc46d8) fp = 2526e6631
 [ 2338.6100882]  netbsd:kern_reboot+0x64(104, 0, 1cbc800, 0, 0, 105a96140) fp = 2526e66e1
 [ 2338.7000889]  netbsd:vpanic+0x18c(104, 0, ff0f0000000001, e0048000, 197f5f8, 0) fp = 2526e6791
 [ 2338.8000898]  netbsd:panic+0x20(1943498, 2526e7188, 1cc4528, 1cc4400, 1cc3000, 104) fp = 2526e6841
 [ 2338.9100906]  netbsd:data_access_fault+0x508(1943498, 68, 69722065020d4e78, 0, 0, 104414b90) fp = 2526e6901
 [ 2339.0300920]  netbsd:1010700+0(2526e72e0, 68, 1018128, 69722065020d4e78, 69722065020d47bd, 118018) fp = 2526e6a31
 [ 2339.1500931]  netbsd:copyin_proc+0x24(69722065020d47bd, 105443000, 500, 69722064074977bd, 101848c, 0) fp = 2526e6c11
 [ 2339.2800947]  netbsd:proc_getauxv+0x74(0, 69722065020d47bd, 105443000, 500, e0048000, 0) fp = 2526e6cd1
 [ 2339.3900951]  netbsd:real_coredump_elf64+0x19c(105a94780, 2526e7678, 2526e7658, 105443000, 500, 69722065020d47bd) fp = 2526e6da1
 [ 2339.5300963]  netbsd:coredump_elf64+0x2c(105a96140, 2526e7910, 1c5fc48, a0, 1, 105a94780) fp = 2526e6f81
 [ 2339.6400972]  netbsd:coredump+0x4ac(105a96140, 2526e7910, 103754700, 0, 4e, 1c70100) fp = 2526e7031
 [ 2339.7500982]  netbsd:sigexit+0x27c(105a96140, 0, 1cc9c00, 0, 10434ac00, 105a94780) fp = 2526e71e1
 [ 2339.8500991]  netbsd:postsig+0x198(105a96140, b, 180000, 105a94780, 103736380, 1c70280) fp = 2526e72c1
 [ 2339.9701000]  netbsd:lwp_userret+0x1ac(b, 0, 105a963b8, 2526e7b70, 105a94780, 105a96140) fp = 2526e73f1
 [ 2340.0801012]  netbsd:data_access_fault+0x470(105a96140, 1000000, 20000, 100000, 91a0002, 105a94780) fp = 2526e74f1
 [ 2340.2001020]  netbsd:1010700+0(2526e7ed0, 30, 40566bd0, ffffffffffffee78, ffffffffffffe000, 105a94780) fp = 2526e7621
 [ 2340.3301031]  netbsd:40566b64+0(ffffffffffffa078, 40787b08, ffffffffffffa078, 40788110, 5310d, 0) fp = ffffffffffff9661
 
 
 I have fixed the copyin* fault handling for this case, but we still get a
 zero sized core file, so it is hard to debug how the process got into
 that state (and the build still fails).
 
 The process has overwritten some parts of its memory with (random?) things,
 and if those random things happen to match certain patterns it would trigger
 the kernel crash.
 
 Probably not worth to further debug with this old version.
 
 Martin