osmo-sgsn crash report

[a***@manateeshome.com]

Hello, I've been working with my nanoBTS units again. But I've noticed some crashes while using GPRS data.

I am currently using the newest git repo for everything. And a nanoBTS 1900 and an iPhone.

Attached is the log of the crash. Please let me know if you need more information.

Regards,
Pierre

[Holger Hans Peter Freyther]

On Mon, Sep 15, 2014 at 04:13:28PM +0000, ***@manateeshome.com wrote:

Hi!

<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
<0010> gprs_ns.c:545 NSEI=101 Tns-alive expired more then 10 times, blocking NS-VC
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
<0010> gprs_ns.c:624 All NS-VCs for NSEI 101 are either dead or blocked!
Program received signal SIGABRT, Aborted.
0x00007ffff69b3445 in raise () from /lib/x86_64-linux-gnu/libc.so.6

it is a known crash with a double free in the defragmentation code (not
freeing will most likely lead to a leak). Are you willing to sponsor
the necessary code-review to make that issue go away?

Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31357:WARN:BH_TRX_ROUTER_TR:rm_s_data_queue_entry.c#195:Pool 2 nearly full
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31663:WARN:BH_TRX_ROUTER_TR:igki_sig.c#741:Pool 2 nearly full

GPRS with the nanoBTS is not very stable. They have known memory
leaks in all versions of their firmware.

holger

[a***@manateeshome.com]

On Tue, Sep 16, 2014 at 01:20 AM, Holger Hans Peter Freyther wrote:On Mon, Sep 15, 2014 at 04:13:28PM +0000, ***@manateeshome.com (mailto:***@manateeshome.com) wrote:

Hi!

osmo-sgsn:

sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52
sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52
sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
gprs_ns.c:545 NSEI=101 Tns-alive expired more then 10 times, blocking NS-VC
sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
gprs_ns.c:624 All NS-VCs for NSEI 101 are either dead or blocked!

Program received signal SIGABRT, Aborted.
0x00007ffff69b3445 in raise () from /lib/x86_64-linux-gnu/libc.so.6

it is a known crash with a double free in the defragmentation code (not
freeing will most likely lead to a leak). Are you willing to sponsor
the necessary code-review to make that issue go away?

I wish I could, but I am not accustomed to debugging code in linux.
I looked over the surrounding code for a bit but it was difficult for me to get down to it without knowing how those are supposed to work...
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31357:WARN:BH_TRX_ROUTER_TR:rm_s_data_queue_entry.c#195:Pool 2 nearly full
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31663:WARN:BH_TRX_ROUTER_TR:igki_sig.c#741:Pool 2 nearly full

GPRS with the nanoBTS is not very stable. They have known memory
leaks in all versions of their firmware.

If thats the case, how are commercial operators coping with those crashes?
Worst I've ever seen is the BTS crashing in 10 minutes of operation with a single iPhone connected.
I don't think thats even close to production level?
Regards,
Pierre