OPENSSL_altivec_probe -- haláleset

 ( NevemTeve | 2013. június 18., kedd - 16:10 )

Van egy ilyen részlet a crypto/ppccpuid.s fájlban:

.globl  .OPENSSL_altivec_probe
.align  4
.OPENSSL_altivec_probe:
.long   0x10000484
        blr
.long   0
.byte   0,12,0x14,0,0,0,0,0

ami a debuggoláskor így néz ki:

Breakpoint 1, 0xdf530548 in OPENSSL_altivec_probe ()
   from /usr/local/lib/libcrypto.so.1.0.1
(gdb) display/i $pc
1: x/i $pc
=> 0xdf530548 :  vor     v0,v0,v0
(gdb) si

Program received signal SIGILL, Illegal instruction.
0xdf530548 in OPENSSL_altivec_probe () from /usr/local/lib/libcrypto.so.1.0.1

a hívó a crypto/ppccap.h, abban egy ilyesmi részlet van:

if (sigsetjmp(ill_jmp,1) == 0) {
        OPENSSL_altivec_probe();
        OPENSSL_ppccap_P |= PPC_ALTIVEC;
}

ez előtt volt egy sigaction, ami beállított egy handlert, ami lenyelné a hibát:

static void ill_handler (int sig) { siglongjmp(ill_jmp,sig); }

Namostan nekem van olyan helyzetem (Apache->Php->OpenSsl, továbbá saját PHP bővitmény is van), amikor ez valamiért nem így történik, hanem megáll a futás.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Kezdek arra hajlani, hogy az OpenSsl ártatlan lehet, hanem a handlere valahogy érvényben maradt(???) és egy független SIGILL-t valamiért az ő rovására írtam. Természetesen a házi fejlesztés a leggyanúsabb, bár azért SIGILL-t C-ben előidézni nem annyira könnyű...

Nem is nehez. Kell egy elkurt C compiler, vagy annak nem megfelelo parametere, egy elszurt asm betet, etc.

---
pontscho / fresh!mindworkz

Á, egyszerűbb, szégyellem is elmondani;)
Elfelejtettem, hogy a dinamikus linker (/usr/lib/librtl.a(shr.o)) hiányában a dinamikus linkelés nem történik meg. Pontosabban, a következmények definiálatlanok, SIGILL éppúgy lehet belőle, mint látszólag helyes működés.

A gond ott kezdődik, hogy a PHP-bővítény futhat a stand-alone PHP-ben is, meg a libphp5.so-ban is, vagyis nem lehet előre megmondani, hogy honnan vegye az unresolved externjeit. Tehát kell a -brtllib opció -- mégpedig a főprogramnak, aki egyrészt a php, másrészt a httpd. Na ez utóbbi maradt ki.

Mégegyszer elnézést kérek az OpenSsl-től az alaptalan vádaskodásért.

Na, az illegal instruction hetet tartjuk akkor. Nekem is volt tegnap egy ilyenem, egy Ubuntu Maverick szervert migraltam at egyik xenrol a masikra, es a ProFTPD egyik modulja a migracio utan megszunt mukodni a celgepen. tobbszor ujra is telepitettem a proftpd-t, sikertelenul, ugyhogy vegul disable lett a vege (nem hasznalt modul volt). Itt nem OpenSSL volt a ludas, hanem tcpwrapper nyug volt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hmmm... dump -H mit mond a modulra? És a főprogramra?

Most nem tudom/akarom megnezni, de meg fogom mindenkepp.

PS: dump? Az nem valami AIX-es cucc? Igaz, hogy elrejtve, de utaltam arra, hogy Linux...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Akkor ez nem volt nagy segítség neked, bocsi;)
(azért a readelf -d <module>.so-t meg lehet nézni, hátha van benne valami feltűnő.
Megj: readelf kimenetéből szerintem ezek a fontosak shared lib ügyben:
egrep '(NEEDED|SONAME|RPATH)')

Koszi, megnezem. Fura, hogy egy sima rsync ilyen szinten bokjon el valamit.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.