Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0?

2009-12-09 Thread Kostik Belousov
On Wed, Dec 09, 2009 at 01:48:38AM -, Steven Hartland wrote:
 I'm currently testing nginx + passenger on FreeBSD 8.0 and I'm seeing a 
 strange
 segv which seems to indicate a core library error in _rtld_error. Could this
 be the case or is the stack just badly corrupted?
 
 (gdb) bt
 #0  0x0008005577dc in _rtld_error () from /libexec/ld-elf.so.1
 #1  0x000800557c3f in _rtld_error () from /libexec/ld-elf.so.1
 #2  0x000800557d5e in _rtld_error () from /libexec/ld-elf.so.1
 #3  0x00080055851b in dladdr () from /libexec/ld-elf.so.1
 #4  0x0008005585f3 in dladdr () from /libexec/ld-elf.so.1
 #5  0x00080055576d in ?? () from /libexec/ld-elf.so.1
 #6  0x0001 in ?? ()
 #7  0x004117f8 in 
 boost::detail::sp_counted_impl_pPassenger::Application::StandardSession::dispose
  (this=0x800768980) at 
 sp_counted_impl.hpp:78
 Previous frame inner to this frame (corrupt stack?)

You need to rebuild rtld with debugging information. Ideally, all shared
objects should have valid debug info.

At least, enter src/libexec/rtld-elf and do
make obj
make depend
make all install DEBUG_FLAGS=-g


pgpmYO9aF9Qst.pgp
Description: PGP signature


Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.0?

2009-12-09 Thread Steven Hartland


- Original Message - 
From: Kostik Belousov kostik...@gmail.com

To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-hackers@freebsd.org; freebsd-sta...@freebsd.org
Sent: Wednesday, December 09, 2009 10:21 AM
Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.0?

This is the trace once world had been recompiled with:-
CFLAGS=-pipe
WITH_CTF=1
DEBUG_FLAGS=-g


#0  0x000800c95eec in thr_kill () at thr_kill.S:3
#1  0x000800b22e9e in _thr_send_sig (thread=0x800f06600, sig=6) at 
/usr/src/lib/libthr/thread/thr_kern.c:92
#2  0x000800b1f878 in _raise (sig=6) at 
/usr/src/lib/libthr/thread/thr_sig.c:187
#3  0x000800d74003 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#4  0x0043b8a7 in Client::threadMain (this=0x800f9cf40) at 
ext/nginx/HelperServer.cpp:516
#5  0x00411302 in boost::_mfi::mf0void, Client::operator() (this=0x7fa45ea8, p=0x800f9cf40) at 
mem_fn_template.hpp:49
#6  0x00411651 in boost::_bi::list1boost::_bi::valueClient* ::operator()boost::_mfi::mf0void, Client, 
boost::_bi::list0 (this=0x7fa45eb8, f...@0x7fa45ea8, a...@0x7fa45d7f) at bind.hpp:232
#7  0x00411696 in boost::_bi::bind_tvoid, boost::_mfi::mf0void, Client, boost::_bi::list1boost::_bi::valueClient*  
::operator() (this=0x7fa45ea8) at bind_template.hpp:20
#8  0x004116bd in boost::detail::function::void_function_obj_invoker0boost::_bi::bind_tvoid, boost::_mfi::mf0void, 
Client, boost::_bi::list1boost::_bi::valueClient*  , void::invoke (

   function_obj_p...@0x7fa45ea8) at function_template.hpp:158
#9  0x0042e73a in boost::function0void, std::allocatorvoid ::operator() (this=0x7fa45ea0) at 
function_template.hpp:825

#10 0x00435760 in oxt::thread::thread_main (fu...@0x7fa45ea0, 
da...@0x7fa45e90) at thread.hpp:107
#11 0x0041310e in boost::_bi::list2boost::_bi::valueboost::functionvoid ()(), std::allocatorvoid  , 
boost::_bi::valueboost::shared_ptroxt::thread::thread_data  ::operator()void (*)(boost::functionvoid ()(), 
std::allocatorvoid , boost::shared_ptroxt::thread::thread_data), boost::_bi::list0 (this=0x800f3ee80, f...@0x800f3ee78, 
a...@0x7fa45f0f) at bind.hpp:289
#12 0x00413196 in boost::_bi::bind_tvoid, void (*)(boost::functionvoid ()(), std::allocatorvoid , 
boost::shared_ptroxt::thread::thread_data), boost::_bi::list2boost::_bi::valueboost::functionvoid ()(), std::allocatorvoid 
 , boost::_bi::valueboost::shared_ptroxt::thread::thread_data   ::operator() (this=0x800f3ee78) at bind_template.hpp:20
#13 0x004131b9 in boost::thread::thread_databoost::_bi::bind_tvoid, void (*)(boost::functionvoid ()(), 
std::allocatorvoid , boost::shared_ptroxt::thread::thread_data), boost::_bi::list2boost::_bi::valueboost::functionvoid 
()(), std::allocatorvoid  , boost::_bi::valueboost::shared_ptroxt::thread::thread_data::run (this=0x800f3ee00) at 
thread.hpp:130

#14 0x00443259 in thread_proxy (param=0x800f3ee00) at 
ext/boost/src/pthread/thread.cpp:127
#15 0x000800b1badd in thread_start (curthread=0x800f06600) at 
/usr/src/lib/libthr/thread/thr_create.c:288
#16 0x in ?? ()
Cannot access memory at address 0x7fa46000
Current language:  auto; currently asm

It seems that in the passenger client threads it calls closeStream which errors 
when
the socket close errors with ENOTCONN
   virtual void closeStream() {
   TRACE_POINT();
   if (fd != -1) {
   int ret = syscalls::close(fd);
   fd = -1;
   if (ret == -1) {
   if (errno == EIO) {
   throw SystemException(A write operation on the session 
stream failed,
   errno);
   } else {
   throw SystemException(Cannot close the session stream,
   errno);
   }
   }
   }
   }

This causes it to call abort on the the thread which then crashes the app with
the above stack trace, which seems really weird. Anyone got any ideas?

   Regards
   steve 




This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: old/unupdated xterm entries in termcap db

2009-12-09 Thread Gary Jennejohn
On Wed, 09 Dec 2009 01:12:04 +0200
Leonidas Tsampros ltsamp...@upnet.gr wrote:

 Why aren't these entries updated in order to match the
 ones that ship with xterm? Am I missing something?
 

Probably because xterm is under ports and termcap under src and it would
not be easy to track changes in ports under src.

The only practical way to keep termcap up to date would be for the
committer updating the port to also check and update termcap under src.
The problem with this is that most ports committers aren't authorized
to make commits under src.

---
Gary Jennejohn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: old/unupdated xterm entries in termcap db

2009-12-09 Thread Dag-Erling Smørgrav
Gary Jennejohn gary.jennej...@freenet.de writes:
 Dag-Erling Smørgrav d...@des.no writes:
  That's not an issue - termcaps don't change all that often.  We should
  just import the new definitions.
 That's a practical attitude, but it begs the question why it hasn't
 happened in the past.

Because what was there worked well enough for most people...

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org