Hi All,
We are experiencing Segmentation Fault intermittently in OSMO-BSC.
We were able to create a crash file and enabled the debug in all logs of OSMO-BSC.
We are using Ettus B210, intel UPBOARD and running in UBUNTU 16.04.
# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.4 LTS Release: 16.04 Codename: xenial
Attached are the debug log file, core dumped file (URL provided for download), config files used, lshw, and lscpu output.
# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 92 Model name: Intel(R) Pentium(R) CPU N4200 @ 1.10GHz Stepping: 9 CPU MHz: 800.000 CPU max MHz: 1101.0000 CPU min MHz: 800.0000 BogoMIPS: 2188.79 Virtualization: VT-x L1d cache: 24K L1i cache: 32K L2 cache: 1024K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms mpx rdseed smap clflushopt sha_ni xsaveopt xsavec xgetbv1 dtherm ida arat pln pts
We also installed the OSMOCOM elements using source and save in the /usr/local directory.
https://www.dropbox.com/s/pedh1zshhe5kmuc/core?dl=0
Best Regard,
Ron Menez ron.menez@entropysolution.commailto:ron.menez@entropysolution.com
Hi Ron,
Thanks for your report!
I can try to reproduce the issue, but if you have it available, the following would be immensely useful:
You've offered the core file as download, but that is of no use without the exact matching binary. Please instead provide the backtrace like:
gdb path/to/osmo-bsc core
bt
If the failure occurs reliably, you can also run osmo-bsc in gdb
gdb --args osmo-bsc -c [...]
When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a backtrace. If you are reproducing it, a network trace (pcap) of the events leading up to the failure would also be helpful.
The default compilation should already include the debug symbols, i.e. CFLAGS containing "-g". Otherwise, the debian feeds also contain packages with debug symbols included.
Ideally, you would create a new issue on osmocom.org in the OsmoBSC project and provide the backtrace, pcap and logs as attachments there. Attaching files to issues is preferable to sending mails with attachments, since everyone subscribed would receive attached files in their mail inboxes; we prefer to avoid that, for netiquette.
For creating issues, I will gladly provide permissions to your registered user. I see Justin Repello and Sonny Lafuente (sharing your email's domain name) registered at osmocom.org, and just gave those users "Developer" permissions. Let me know of any other users you would like me to enable. The enable step is merely to avoid spam, you're more than welcome to join anytime.
Thanks!
~N
Hi Neels,
Thanks for your report!
I can try to reproduce the issue, but if you have it available, the following would be immensely useful:
You've offered the core file as download, but that is of no use without the exact matching binary. Please instead provide the backtrace like:
gdb path/to/osmo-bsc core bt
If the failure occurs reliably, you can also run osmo-bsc in gdb
gdb --args osmo-bsc -c [...]
When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a backtrace. If you are reproducing it, a network trace (pcap) of the events leading up to the failure would also be helpful.
We’ll be sharing the matching binary for this. We’ll try to replicate the segfault again and share the backtrace.
The default compilation should already include the debug symbols, i.e. CFLAGS containing "-g". Otherwise, the debian feeds also contain packages with debug symbols included.
Ideally, you would create a new issue on osmocom.orghttp://osmocom.org in the OsmoBSC project and provide the backtrace, pcap and logs as attachments there. Attaching files to issues is preferable to sending mails with attachments, since everyone subscribed would receive attached files in their mail inboxes; we prefer to avoid that, for netiquette.
We already registered to osmocom.orghttp://osmocom.org and we’ll share the backtrace, logs, and pcap files to the issue register.
Noted on sending mails with attachments. Apologies for our previous emails.
Best Regard,
Ron Menez ron.menez@entropysolution.commailto:ron.menez@entropysolution.com
On Apr 16, 2018, at 7:18 PM, Neels Hofmeyr <nhofmeyr@sysmocom.demailto:nhofmeyr@sysmocom.de> wrote:
Hi Ron,
Thanks for your report!
I can try to reproduce the issue, but if you have it available, the following would be immensely useful:
You've offered the core file as download, but that is of no use without the exact matching binary. Please instead provide the backtrace like:
gdb path/to/osmo-bsc core bt
If the failure occurs reliably, you can also run osmo-bsc in gdb
gdb --args osmo-bsc -c [...]
When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a backtrace. If you are reproducing it, a network trace (pcap) of the events leading up to the failure would also be helpful.
The default compilation should already include the debug symbols, i.e. CFLAGS containing "-g". Otherwise, the debian feeds also contain packages with debug symbols included.
Ideally, you would create a new issue on osmocom.orghttp://osmocom.org in the OsmoBSC project and provide the backtrace, pcap and logs as attachments there. Attaching files to issues is preferable to sending mails with attachments, since everyone subscribed would receive attached files in their mail inboxes; we prefer to avoid that, for netiquette.
For creating issues, I will gladly provide permissions to your registered user. I see Justin Repello and Sonny Lafuente (sharing your email's domain name) registered at osmocom.orghttp://osmocom.org, and just gave those users "Developer" permissions. Let me know of any other users you would like me to enable. The enable step is merely to avoid spam, you're more than welcome to join anytime.
Thanks!
~N
-- - Neels Hofmeyr <nhofmeyr@sysmocom.demailto:nhofmeyr@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte
Hi Neels,
Issue is now in osmocom.orghttp://osmocom.org issues list. Kindly see URL below:
https://osmocom.org/issues/3182
Thanks.
Best Regard,
Ron Menez ron.menez@entropysolution.commailto:ron.menez@entropysolution.com
On Apr 17, 2018, at 4:48 PM, Ron <ron.menez@entropysolution.commailto:ron.menez@entropysolution.com> wrote:
Hi Neels,
Thanks for your report!
I can try to reproduce the issue, but if you have it available, the following would be immensely useful:
You've offered the core file as download, but that is of no use without the exact matching binary. Please instead provide the backtrace like:
gdb path/to/osmo-bsc core bt
If the failure occurs reliably, you can also run osmo-bsc in gdb
gdb --args osmo-bsc -c [...]
When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a backtrace. If you are reproducing it, a network trace (pcap) of the events leading up to the failure would also be helpful.
We’ll be sharing the matching binary for this. We’ll try to replicate the segfault again and share the backtrace.
The default compilation should already include the debug symbols, i.e. CFLAGS containing "-g". Otherwise, the debian feeds also contain packages with debug symbols included.
Ideally, you would create a new issue on osmocom.orghttp://osmocom.org/ in the OsmoBSC project and provide the backtrace, pcap and logs as attachments there. Attaching files to issues is preferable to sending mails with attachments, since everyone subscribed would receive attached files in their mail inboxes; we prefer to avoid that, for netiquette.
We already registered to osmocom.orghttp://osmocom.org/ and we’ll share the backtrace, logs, and pcap files to the issue register.
Noted on sending mails with attachments. Apologies for our previous emails.
Best Regard,
Ron Menez ron.menez@entropysolution.commailto:ron.menez@entropysolution.com
On Apr 16, 2018, at 7:18 PM, Neels Hofmeyr <nhofmeyr@sysmocom.demailto:nhofmeyr@sysmocom.de> wrote:
Hi Ron,
Thanks for your report!
I can try to reproduce the issue, but if you have it available, the following would be immensely useful:
You've offered the core file as download, but that is of no use without the exact matching binary. Please instead provide the backtrace like:
gdb path/to/osmo-bsc core bt
If the failure occurs reliably, you can also run osmo-bsc in gdb
gdb --args osmo-bsc -c [...]
When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a backtrace. If you are reproducing it, a network trace (pcap) of the events leading up to the failure would also be helpful.
The default compilation should already include the debug symbols, i.e. CFLAGS containing "-g". Otherwise, the debian feeds also contain packages with debug symbols included.
Ideally, you would create a new issue on osmocom.orghttp://osmocom.org/ in the OsmoBSC project and provide the backtrace, pcap and logs as attachments there. Attaching files to issues is preferable to sending mails with attachments, since everyone subscribed would receive attached files in their mail inboxes; we prefer to avoid that, for netiquette.
For creating issues, I will gladly provide permissions to your registered user. I see Justin Repello and Sonny Lafuente (sharing your email's domain name) registered at osmocom.orghttp://osmocom.org/, and just gave those users "Developer" permissions. Let me know of any other users you would like me to enable. The enable step is merely to avoid spam, you're more than welcome to join anytime.
Thanks!
~N
-- - Neels Hofmeyr <nhofmeyr@sysmocom.demailto:nhofmeyr@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte
-
Neels Hofmeyr -
Ron