[Home]

Summary:ASTERISK-08680: cant start * on PowerPC
Reporter:Clod Patry (junky)Labels:
Date Opened:2007-01-29 10:47:15.000-0600Date Closed:2011-06-07 14:00:43
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt_registry.txt
( 1) pthread_create.txt
Description:After a cross-compile, if I try to start *, it coredump
in test_for_thread_safety(), particulary, when trying to create the thread.


Ive tried to return 0 from that function, but i cant use chan_sip after that.


GDB session is attached.




****** ADDITIONAL INFORMATION ******

[root@10.2.110.195 bin]# uname -a
Linux 10.2.110.195 2.6.11 #1 Wed Nov 29 17:26:24 EST 2006 ppc unknown unknown GN
U/Linux
[root@10.2.110.195 bin]#

this is UClibc
Comments:By: Jared Smith (jsmith) 2007-01-29 12:34:27.000-0600

Can you please show us how you setup your cross-compile environment, etc?  My gut tells me it's a cross-compile problem.  It's gonna be near impossible to debug without knowing more about your system, etc.
By: Clod Patry (junky) 2007-01-30 09:14:44.000-0600

i used:
CC='distcc powerpc-uClibc-linux-gcc' STRIP=`which powerpc-uClibc-linux-strip` HOSTCC=gcc ./configure --host=powerpc-uClibc-linux --without-pwlib --without-curl

make INSTALL_PATH=/home/cpatry/Starteam/rep_ThirdParties/Asterisk_LAG/Makefiles/Sbc -j6

make DESTDIR=/home/cpatry/Starteam/rep_ThirdParties/Asterisk_LAG/Makefiles/Sbc install


do you see anything wrong?

Are ya aware that * has trouble with uclibc?
By: Jason Parker (jparker) 2007-01-30 10:14:28.000-0600

All I do to cross-compile is just `./configure --host=powerpc-uClibc-linux --without-pwlib --without-curl`.  Can you try removing the other "stuff"?
By: Clod Patry (junky) 2007-01-30 10:39:01.000-0600

in ur example (with removing all my stuff), how do you make & make install to support all ur options said in the configure? since make doesnt support --host.



configure: Package configured for:
configure: OS type  : linux-gnu
configure: Host CPU : powerpc
configure: Cross Compilation = YES
[cpatry@chouffe asterisk-1.4.0 (Mitos 2.0.2)]$ make
make[1]: Entering directory `/home/cpatry/asterisk-1.4.0/menuselect'
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[1]: *** [autoconfig.h] Error 1
make[1]: Leaving directory `/home/cpatry/asterisk-1.4.0/menuselect'
make: *** [menuselect/menuselect] Error 2
[cpatry@chouffe asterisk-1.4.0 (Mitos 2.0.2)]$
By: Jason Parker (jparker) 2007-01-30 10:55:42.000-0600

It should "Just Work".

When you do ./configure, it stores stuff in the makeopts file, which make should pick up.  Try doing a make distclean, then re-run ./configure (with the options I said), then run make
By: Clod Patry (junky) 2007-01-30 11:02:24.000-0600

its exactly what i said.
im using 1.4.0 (tarball), bug?
By: Clod Patry (junky) 2007-01-30 13:21:56.000-0600

Compiled directly with glibc and no cross results a successful *.

But cross with uclibc result the same stuff ever & ever.
By: Clod Patry (junky) 2007-01-31 10:16:03.000-0600

Qwell: any answer for my prev question?

I ran thru a gdb session, this is what i got.
I've no idea what could be the problem: problem with a lib or the cross-compile which goes wrong.


[root@10.2.110.195 sbin]# gdb  ./asterisk  
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb)
(gdb) run -c -C ~cpatry/asterisk/asterisk.conf
Starting program: /home/cpatry/Starteam/rep_ThirdParties/Asterisk_LAG/Mitos_2.0/
uClibc-Linux/ppc/Release/usr/sbin/asterisk -c -C ~cpatry/asterisk/asterisk.conf
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
warning: Cannot initialize thread debugging library: unknown thread_db error '22
'
Asterisk 1.4.0, Copyright (C) 1999 - 2006 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for detail
s.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
[ Booting...
[ Reading Master Configuration ]
[ Initializing Custom Configuration Options ]

Program received signal SIG32, Real-time event 32.
0x30050bc8 in __uClibc_syscall () from /uClibc/lib/libdl.so.0
(gdb)
By: Clod Patry (junky) 2007-01-31 15:47:20.000-0600

if i comment:
7775                 ast_db_put("SIP/Registry", peer->name, data);

everything works fine!
By: Jared Smith (jsmith) 2007-02-01 10:50:12.000-0600

Oh, it's having a problem with the AstDB stuff then... and chan_sip stored the registry information in the AstDB database.  Sounds like a problem with your cross-compiler not finding something rigth with the berkeley db stuff.
By: Clod Patry (junky) 2007-02-06 14:56:07.000-0600

i simply ignored the call to ast_db_put, cause storing the registry isnt a need forme.

but now, ive remarqued something really bad, if i unload chan_sip,
im getting:
17312                   pthread_kill(monitor_thread, SIGURG);
(gdb) n
17313                   pthread_join(monitor_thread, NULL);
(gdb) n
17315           monitor_thread = AST_PTHREADT_STOP;
(gdb) n
522             return pthread_mutex_unlock(pmutex);
(gdb) s
17315           monitor_thread = AST_PTHREADT_STOP;
(gdb) n
522             return pthread_mutex_unlock(pmutex);
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0x0ff751ac in pthread_key_create () from /uClibc/lib/libpthread.so.0
(gdb) bt
#0  0x0ff751ac in pthread_key_create () from /uClibc/lib/libpthread.so.0
#1  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
#2  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
#3  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
#4  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
ASTERISK-1  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
ASTERISK-2  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
ASTERISK-3  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
ASTERISK-4  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
ASTERISK-5  0x0ff89bc8 in __pthread_handles () from /uClibc/lib/libpthread.so.0
Previous frame inner to this frame (corrupt stack?)
(gdb)

and the whole machine is jammed, ive to reset it.

And that's with patch from http://svn.digium.com/view/asterisk/branches/1.4/channels/chan_sip.c?r1=51558&r2=51788
By: Clod Patry (junky) 2007-02-12 10:46:25.000-0600

any news here?
By: Joshua C. Colp (jcolp) 2007-02-15 19:47:15.000-0600

I honestly think it's your cross compiling, something about it is being done incorrectly. You are getting issues in the most basic of things (pthreads) and we know that Asterisk cross compiles fine.
By: Clod Patry (junky) 2007-03-07 21:42:48.000-0600

We fixed * code at the office with some engineers.
By: Clod Patry (junky) 2007-03-08 10:07:05.000-0600

Trust me, it requires a lot of works.
we had to hard-code a lot of stuff here and there.

So changes are needed.
By: Serge Vecher (serge-v) 2007-03-08 10:56:30.000-0600

junky, afaik, the 'fixed' status is for reports that have associated changes committed into svn. Since nothing was committed, I thought that the code changes you mentioned did not need to go into the svn. If changes need to go in, please upload them as a patchfile...