./configure[14624]: 10682862 Memory fault(coredump)

Ez egy oci8-3.4.0 egy php-8.5.0-ban, Aix7.2 rendszerben. Nyilván valami jó oka van rá, csak még ki kell deríteni, hogy mi az.

./configure[14624]: 10682862 Memory fault(coredump)
$ cat -n ./configure | grep -B3 -A2 14624
 14621  
 14622    { $as_echo "$as_me:${as_lineno-$LINENO}: creating build directories" >&5
 14623  $as_echo "$as_me: creating build directories" >&6;}
 14624    $php_shtool mkdir -p $BUILD_DIR

Szerk 2025.12.04. 16:42
Ez most kicsit antiklímatikus: egy másik Aix-ról (6.1) átmásolt /bin/sh jól működik. Szóval tessék szépen továbbmenni, nincs itt semmi látnivaló.

( NevemTeve | 2025. 12. 01., h – 15:55 )

Megpróbáltam fokozni a debuggolást. De sikerült?!

-./configure \
+bash -x ./configure \

Nem, mert így nem írja a hibát. A default shell egy olyan ksh, amit még a verziószámok feltalálása előtt készítettek.

$ ls -l /bin/sh /bin/ksh
-r-xr-xr-x 5 bin bin 325048 Sep  9  2020 /bin/ksh
-r-xr-xr-x 5 bin bin 325048 Sep  9  2020 /bin/sh

( Nyosigomboc v | 2025. 12. 01., h – 16:24 )

Oracle, PHP, es AIX egyben. Jo lehet :)

Legalabb nem 3-as PHP, mar ez is valami.

Itt 8.3-as php-ig irjak, nem tudom, ez szamit-e.

A strange game. The only winning move is not to play. How about a nice game of chess?

( NevemTeve | 2025. 12. 01., h – 16:38 )

truss-szal próbálkozom, ebben látszik egy processz, ami elég rövid karriert fut be:

27001250:       24052047: kfork()                               = 25559374
25559374:       kfork()         (returning as child ...)        = 0
27001250:       24052047: sigprocmask(2, 0x2FF20C90, 0x00000000) = 0
25559374:       31392201: _getpid()                             = 25559374
27001250:       24052047: sigprocmask(1, 0x2FF20C90, 0x00000000) = 0
25559374:       31392201: _sigaction(25, 0x00000000, 0x2FF20BD0) = 027001250:   24052047: _sigaction(20, 0x00000000, 0x2FF20BC0)
 = 0
25559374:       31392201: _sigaction(25, 0x2FF20BD0, 0x2FF20BE0) = 027001250:   24052047: _sigaction(20, 0x2FF20BC0, 0x2FF20BD0) = 0
 
25559374:       31392201: _sigaction(15, 0x00000000, 0x2FF20BD0) = 0
25559374:       31392201: _sigaction(15, 0x2FF20BD0, 0x2FF20BE0) = 0
25559374:       31392201: _sigaction(13, 0x00000000, 0x2FF20BD0) = 0
25559374:       31392201: _sigaction(13, 0x2FF20BD0, 0x2FF20BE0) = 0
25559374:       31392201: _sigaction(3, 0x00000000, 0x2FF20BD0) = 0
25559374:       31392201: _sigaction(3, 0x2FF20BD0, 0x2FF20BE0) = 0
25559374:       31392201: _sigaction(1, 0x00000000, 0x2FF20BD0) = 0
25559374:       31392201: _sigaction(1, 0x2FF20BD0, 0x2FF20BE0) = 0
25559374:       31392201: _sigaction(0, 0x00000000, 0x2FF20BD0) Err#22 EINVAL
25559374:       31392201: _sigaction(0, 0x2FF20BD0, 0x2FF20BE0) Err#22 EINVAL
25559374:           Received signal #11, SIGSEGV [default]
25559374:       *** process killed ***

Aholis:

15 SIGTERM, 13 SIGPIPE, 3 SIQUIT, 1 SIGHUP, 0 WTF 
Mindenesetre a az utsó sigaction mögött kellene jöjjön az execve csak valamiért SIGSEGV jön helyette.

( NevemTeve | 2025. 12. 01., h – 17:04 )

Ennek talán semmi köze semmihez, csak mutatja, hogy milyen jóságok vannak ebben az iparban:

20185572:       37552415: execve("/usr/bin/as_var+=2", 0x200129B8, 0x200AEDF8) Err#2  ENOENT
20185572:       37552415: execve("/usr/bin/X11/as_var+=2", 0x200129B8, 0x200B8B28) Err#2  ENOENT
22282558:       31719807: statx("/usr/bin/as_var+=2", 0x2FF1DB98, 128, 010) Err#2  ENOENT
22282558:       31719807: statx("/usr/bin/X11/as_var+=2", 0x2FF1DB98, 128, 010) Err#2  ENOENT
23069062:       32309507: execve("/usr/bin/as_var+=2", 0x20098968, 0x200A1AF8) Err#2  ENOENT
23069062:       32309507: execve("/usr/bin/X11/as_var+=2", 0x20098968, 0x200A4FA8) Err#2  ENOENT

Ha nem is talált as_var+=2 nevű programot, legalább szorgalmasan kereste. Lehet, hogy ez valami bashizm.

Az lesz, csak jobb lenne azt remélhetni, hogy a Rend és Káosz örök küzdelmében nem itt és most diadalmaskodik az utóbbi. Akarom mondani, jó lenne valami magyarázat.

Szerk: ez a fentemlített változó-összeadás csak egy próba, hogy tud-e optimalizálni a stringtoldozgatás műveletnél (az első az optimalizált, a második a kompatibilis"):

var+=" $toldalek"
var="$var $toldalek"

Ennél már talán csak egy array lenne jobb, ami viszont szintén nincs minden shell-ben.

Azt ertem, hogy azert fizetnek, hogy valamilyen alapvetoen Linuxra szant dolgot valami miatt AIX-on futtass, sokszor teljesen mas korszakbeli verziokkal.

Azt viszont nem, hogy miert jo pluszban a ksh-val onszopatas. Jellemzoen ott van egy script tetejen, hogy mivel kell futtatni, pl. /usr/bin/python3 vagy jobb esetben env-vel ugyanez. Vagy #!/bin/bash, egyszerubb esetben sh. Miert jobb ezt felulbiralni, es olyan shellre raeroszakolni, ami csak reszben kompatibilis vele?

A strange game. The only winning move is not to play. How about a nice game of chess?

Akkor nincs mas hatra, mint hogy jelented nekik, hogy nem sh, hanem bash. Vagy egyszeruen atirhatod az elso sort, esetleg kezzel bashhel inditod. Gondolom azert a bash AIX-en is elerheto, ha mas nem, lehet azt is forditani.

A strange game. The only winning move is not to play. How about a nice game of chess?

Ja, ezt meg elfelejtettem idetenni:

Chaos is found in greatest abundance wherever order is being sought. It always defeats order, because it is better organized.                                  
-Terry Pratchett

A strange game. The only winning move is not to play. How about a nice game of chess?

( NevemTeve | 2025. 12. 02., k – 08:45 )

Esetleg releváns:

https://access.redhat.com/solutions/739193

https://github.com/ksh93/ksh/issues/144 

A kérdéses Aix-on ez az utóbbi hibát okoz a ksh93-ban, de működik a ksh88-ban. A hibaüzenet különbözik, ez Segmentation fault (core dumped) A stacktrace-ben ilyesmi ismétlődik:

#312 0x000000010005792c in IPRA.$parserep ()
#313 0x000000010005c170 in IPRA.$parse ()
#314 0x0000000100059d6c in IPRA.$parse ()
#315 0x0000000100058e68 in IPRA.$parse ()
#316 0x0000000100059c5c in IPRA.$parse ()

( NevemTeve | 2025. 12. 02., k – 12:08 )

ksh fordítása Aix-on addig el sem kezdődik, amíg nem alkotunk egy ilyen scriptet:

#!/bin/sh
unset LIBPATH
exec /opt/freeware/bin/gcc "$@"

Nyilván valamilyen múlhatatlan jócselekedetet kell végrehajtania a LIBPATH-tal.

( NevemTeve | 2025. 12. 02., k – 13:15 )

Csak hogy el ne bízzam magam:

/usr/include/grp.h:184:29: error: 'L_cuserid' undeclared here (not in a function); did you mean 'cuserid'?
         char    _interpline[GRPLINLEN+1];
                             ^~~~~~~~~

Mifene az a grp, hogy az elején kezdjük?
 

    163 #ifdef _THREAD_SAFE
    166 #define GRPLINLEN       (L_cuserid) + ((L_cuserid + 1) * MAXGRP) + 14
    168 struct _grjunk
    184         char    _interpline[GRPLINLEN+1];
    185 };

Nagyon jogosan a stdio.h -ból jön:

    483 #define L_ctermid       9
    484 #if (defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE<200112L) || defined(_ALL_SOURCE)
    485 #define L_cuserid       9
    486 #endif

( NevemTeve | 2025. 12. 02., k – 13:57 )

Azonkívül hoz magával egy saját stdio.h-t, mert nem bízik az AIX-ében... Persze abban nincs ilyen L_cuserid

( bennyh | 2025. 12. 02., k – 15:25 )

Fizetnek neked ezért eleget vagy mazoista vagy?

A docker még vállalható, nagy szar ugyan, de meg lehet tanulni. A gond ott van, hogy afölött még számtalan sok megkönnyítő termék van, amiknek a nevét sem tudom megjegyezni, valami Open Racsni nálunk a pillanatnyi divat, de lehet, hogy januártól ismét más lesz.

Ilyesmi feelingem van: https://medium.com/hackernoon/how-it-feels-to-learn-javascript-in-2016-…

( NevemTeve | 2025. 12. 03., sze – 20:58 )

Lehet, hogy elege lett a környezeti változókból, ezt abból gondolom, hogy megszórtam debug-kiírásokkal:

  14616 (echo 'Line 14616'; date; set) >>debug.configure/$(date +%Y%m%d.%H%M%S).14616.log
  14617 phplibdir="$(pwd)/modules"
  14618 (echo 'Line 14618'; date; set) >>debug.configure/$(date +%Y%m%d.%H%M%S).14618.log

Ebből a 14616-ost még megcsinálta, a 14618-at már nem.