apache20+freebsd70 graceful seg. violation - asi vyreseno (mhash.so)

[michal_sjx]

Ahoj,

diky za tipy. Jednou uz jsem mel problemy s php a spolecne s odstranenim 
nejakeho modulu bylo po problemu.

Zkusil jsem rekompilace, jak pises, ale bez uspechu. BTW pouzivam 
prefork (je to default).

Nakonec ale asi vyreseno. Zkusil jsem vyhodil virtualhosty .. nestacilo, 
ale vyhodil jsem cele php a to pomohlo. Takze jsem se po modulech a je 
to tento ";extension=mhash.so". Takze jsem ho zakomentoval a je po 
problemu :).

Kazdopadne dekuji za pomoc.

PS a k cemu je WITH_KQUEUE_SUPPORT?

Michal

Marian Cerny napsal(a):
> Zdravim,
> 
> On 2008-05-11 01:26 +0200, michal_sjx wrote:
>> Xeon quad, FreeBSD 7.0-STABLE i386, Apache-2.0.63
>>
>> # apachectl -k graceful
>> nebo # /usr/local/etc/rc.d/apache2 reload
>>
>> vyvola signal 11. Pri debugu core souboru je na stacku neco s pthread, 
>> ale tomu uz moc nerozumim/nevim co s tim.
> 
> my tu mame Core 2 Duo/Quad, apache-2.0.59/63, FreeBSD 6.2/6.3. Problem s
> reloadom nemam. Ale pouzivam perfork MPM. Worker MPM som skusal, ale
> boli s nim problemy. Teda samotny apache bol v pohode, ale problemy boli
> v kombinacii s PHP. Je tam uz principialny problem, ak niektore vlakno
> spravi neplatny pristup do pameti, tak spadne cely apache.
> 
>> (gdb) bt
>> #0  0x28f63d90 in ?? ()
>> #1  0x28323e8e in _pthread_main_np () from /lib/libc.so.7
>> #2  0x282dc53c in __res_state () from /lib/libc.so.7
>> #3  0x28305c87 in __h_errno () from /lib/libc.so.7
>> #4  0x28212f58 in apr_getnameinfo () from /usr/local/lib/apache2/libapr-0.so.9
>> #5  0x0806d47e in ap_fini_vhost_config ()
>> #6  0x0806c017 in main ()
> 
> Ten backtrace je pri kazdom restarte rovnaky? Pretoze ja som mal celkom
> problemy s analyzovanim multivlaknovych procesov - myslim, ze bolo
> potrebne sa najprv prepnut na spravne vlakno a tam pozriet backtrace.
> 
> V pripade, ze je toto to miesto, kde to pada, tak moze byt problem
> niekde s konfiguraciou. ap_fini_vhost_config() by sa vola po tom, co
> boli nacitane konfiguracne subory. Vytvara to nejake tabulky pre vhosty.
> Takze by si mohol skusit nejake vhosty zakomentovat, ci to bude robit aj
> tak. Tiez mozes skusit pustit testy konfigurakov httpd -t alebo -S. Pri
> starte alebo restarte to nic podozrive nevypise do logov?
> 
>> A pokud se to nikomu nestava, prosil bych o radu co s tim mohu udelat 
>> (krome scriptu na znovuspusteni ;) ). Tento pad se vyvolava napriklad 
>> rotovanim logu, kde je nastaven -HUP na rodicovsky proces apache.
> 
> Mozno ze je cast apache nejako divne skompilovana. Mohol by si vyskusat
> prekompilovat vsetky porty, ktore ktore zavisia na apachovi, alebo na
> ktorych zavisi apache:
> 
> 	portupgrade -Rf apache\*
> 	portupgrade -rf apache\*
> 
> Tiez mozes skusit prekompilovat apache s debug informaciami (asi
> najlepsie WITH_DEBUG). Ja bezne prekladam apache takto:
> 
> 	# Apache
> 	WITH_MPM = prefork
> 	WITH_PROXY_MODULES = YES
> 	WITH_KQUEUE_SUPPORT = YES
> 	#WITH_DEBUG=YES
> 
> 	# ak spadne apache, chceme vediet preco
> 	.if ${.CURDIR} == "/usr/ports/www/apache20"
> 	CFLAGS += "-g"
> 	STRIP =
> 	.endif
> 
> 	# apache vecsinou pada niekde v php, chceme vediet preco
> 	.if ${.CURDIR} == "/usr/ports/lang/php5"
> 	CFLAGS += "-g"
> 	STRIP =
> 	.endif
> 
> Tiez mozes skusit perfork namiesto worker MPM.
> 
> Marian