[Home]

Summary:ASTERISK-02185: SIGBUS on sparc64/Linux
Reporter:xming (xming)Labels:
Date Opened:2004-08-03 17:32:46Date Closed:2011-06-07 14:10:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:asterisk get a sigbus and crashes with "Bus error" right after playing the demo sounds using sip

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

I have tweaked the Makefile of core asterisk a bit so that it compiles and runs but crashes right after this:

-- Registered SIP '3000' at xxx.xxx.xxx.xxx port 5060 expires 1800
   -- Saved useragent "X-Lite Free World Dialup build 1101" for peer 3000
Aug  3 23:51:52 WARNING[213005]: chan_sip.c:673 retrans_pkt: Maximum retries exceeded on call D30DD7B1-9033-4337-9F90-5E2199A58475@192.168.0.3 for seqno 31816 (Non-critical Response)
   -- Executing Playback("SIP/3000-f902", "demo-echotest") in new stack
   -- Playing 'demo-echotest' (language 'en')
Bus error

tried gdb:
gdb /opt/asterisk/sbin/asterisk
Starting program: /opt/asterisk/sbin/asterisk
Program received signal SIG32, Real-time event 32.
0x70060a94 in pthread_getconcurrency () from /lib/libpthread.so.0

gdb /opt/asterisk/sbin/asterisk
(gdb) handle SIG32 pass noprint nostop

(gdb) handle SIG32 pass noprint nostop
Signal        Stop      Print   Pass to program Description
SIG32         No        No      Yes             Real-time event 32
(gdb) run
Starting program: /opt/asterisk/sbin/asterisk
Program exited normally.

steeping trough in gdb
asterisk.c:1724:                daemon(0,0);
(gdb) step
1718                    fprintf(f, "%d\n", getpid());
(gdb) step
1719                    fclose(f);
(gdb) step
1724                    daemon(0,0);
(gdb) step

Program exited normally.

Configuration:

H/W: ultrasparc 64-bit/big endian SMP (2x450Mhz)

OS: Gentoo Sparc Linux Linux host 2.4.26 #2 SMP Tue Jul 27 09:53:23 CEST 2004 sparc64 sun4u TI UltraSparc II  (BlackBird) GNU/Linux, /lib/libc-2.3.2.so /lib/libthread_db-1.0.so

*: RC1 and CVS-HEAD-20040728 same result

TIA

Ming-Wei
Comments:By: Tilghman Lesher (tilghman) 2004-08-03 17:36:07

Doesn't a SIGBUS generally indicate a hardware problem (i.e. bad memory)?
By: Mark Spencer (markster) 2004-08-03 19:48:31

Not a major bug, we don't claim sparc compatibility but it's nice to know it is close.
By: xming (xming) 2004-08-04 01:08:27

meaning of sigbus:

This signal is raised when your program accesses memory in an invalid way. This signal by default causes your program to terminate and dump core. Bus Errors often occur when you access unaligned memory on a machine that doesn't support unaligned memory accesses. It can also occur if you access mmap(2)'d memory beyond the end of the file but within the region of the mmap(2).

Strange thing is that people are running * on Sparc64/Solaris and Sparc63/OpenBSD with less problems. Could it be that * sees it is on Linux and makes to much assumption that the hardware is i386 (little endian)

Ming-Wei

PS: to me it is still a crash :)
By: Mark Spencer (markster) 2004-08-04 12:56:58

Does it only happen with GSM transcoding?
By: xming (xming) 2004-08-04 15:55:23

Great hint,

these codec g711a g711u g726 work when used for the sip communication. I can hear the demo and echo (they are .gsm file) and echo test works.

So it is not a transcoding issue IMO, I tried the libgsm.a from sox (sox works here without SIGBUS) linked codec_gsm and format_gsm with it and it still SIGBUS.

The only ATM to reproduce is to use GSM for the sip comm. and connect to the demo sounds.

Ming-Wei

edited on: 08-04-04 15:42
By: Mark Spencer (markster) 2004-08-05 18:38:41

Can you try this on Linux/x86 using precisely the identical configuration and see what happens?

If that works, run it under valgrind and see if it tells you something more.
By: xming (xming) 2004-08-07 16:12:29

ok I will do that. Just a remark AFAIK valgrind is only for i386 and not for UltraSparc, isn't it?
By: Mark Spencer (markster) 2004-08-07 16:14:28

Yes, that would be why I was suggesting you run valgrind on x86 so that we can see if we can find the problem using valgrind.
By: Olle Johansson (oej) 2004-08-14 12:43:47

Housekeeping: Any updates? Is this report still valid with the latest CVS?
By: xming (xming) 2004-08-14 16:35:45

it is still valid for CVS-HEAD-20040802, should I try the latest CVS? Are there any significant changes?

If not and when I have time I will setup a x86 box to test and run valgrind with it like Mark suggested

Ming-Wei
By: Brian West (bkw918) 2004-08-22 23:05:07

Any updates?
By: Mark Spencer (markster) 2004-08-31 15:18:19

Can you update and let me know if this is now fixed?
By: Mark Spencer (markster) 2004-09-02 00:07:04

Looks like the user lost interest.