Crash Diagnostic Decode

S

SandyMac

Member
In checking out my system for a problem with both decrypt and detect ads, I experienced a couple of crashes. I ran the crash diag and it provided the following details of the last 2 (various others with same failures):
Code: 
Thu Sep 27 17:27:49 BST 2018
Core was generated by `/usr/bin/humaxtv'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000 in ?? ()
[Current thread is 1 (Thread 700)]
Thread
#0  0x00000000 in ?? ()
Thread 111
#0  0x2c58be3c in recvmsg () from /lib/libpthread.so.0
#1  0x2c58be20 in recvmsg () from /lib/libpthread.so.0
Thread 109
#0  0x2c58b068 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x2c584568 in pthread_mutex_lock () from /lib/libpthread.so.0
#2  0x2c0dcbe4 in NEXUS_P_Scheduler_Step () from /usr/lib/libnexus.so
#3  0x2c0dd160 in ?? () from /usr/lib/libnexus.so
Thread 86
#0  0x2c58be3c in recvmsg () from /lib/libpthread.so.0
#1  0x2c58be20 in recvmsg () from /lib/libpthread.so.0
Thread 74
#0  0x2c59fc20 in select () from /lib/libc.so.0
#1  0x2aadd918 in _ftext () from /var/lib/humaxtv_backup/mod/libnugget.so
#2  0x00000020 in ?? ()
Thread 73
#0  0x2c57a1ec in mq_timedreceive () from /lib/librt.so.0
#1  0x2c57a1cc in mq_timedreceive () from /lib/librt.so.0
Thread 70
#0  0x2c58b5dc in read () from /lib/libpthread.so.0
#1  0x2c58b5c0 in read () from /lib/libpthread.so.0
Thread 68
#0  0x2c59fc20 in select () from /lib/libc.so.0
#1  0x008fd36c in ?? ()
Thread 5
#0  0x2c58ba6c in accept () from /lib/libpthread.so.0
#1  0x2c58ba50 in accept () from /lib/libpthread.so.0
Thread 4
#0  0x2c59fc20 in select () from /lib/libc.so.0
#1  0x0089b848 in ?? ()

*********** Core file /mod/core/humaxtv.1538147056.350 ***********
Fri Sep 28 16:04:16 BST 2018
Core was generated by `/usr/bin/humaxtv'.
Program terminated with signal 10, Bus error.
#0  0x0064ff40 in ?? ()
[Current thread is 1 (Thread 1492)]
Thread
#0  0x0064ff40 in ?? ()
Thread 108
#0  0x2c58be3c in recvmsg () from /lib/libpthread.so.0
#1  0x2c58be20 in recvmsg () from /lib/libpthread.so.0
Thread 107
#0  0x2c59e6bc in ioctl () from /lib/libc.so.0
#1  0x2c07a24c in ?? () from /usr/lib/libnexus.so
Thread 82
#0  0x2c58be3c in recvmsg () from /lib/libpthread.so.0
#1  0x2c58be20 in recvmsg () from /lib/libpthread.so.0
Thread 70
#0  0x2c59fc20 in select () from /lib/libc.so.0
#1  0x2aadd918 in _ftext () from /var/lib/humaxtv_backup/mod/libnugget.so
#2  0x00000020 in ?? ()
Thread 69
#0  0x2c57a1ec in mq_timedreceive () from /lib/librt.so.0
#1  0x2c57a1cc in mq_timedreceive () from /lib/librt.so.0
Thread 66
#0  0x2c58b5dc in read () from /lib/libpthread.so.0
#1  0x2c58b5c0 in read () from /lib/libpthread.so.0
Thread 64
#0  0x2c59fc20 in select () from /lib/libc.so.0
#1  0x008fd36c in ?? ()
I can't seem to find any information on crash faults. Can someone point me or advise what these are. Thanks in advance.
 
Last edited by a moderator:
SandyMac said:
I can't seem to find any information on crash faults. Can someone point me or advise what these are. Thanks in advance.
Click to expand...

These are both crashes caused by bugs in the Humax code but I can't tell exactly what caused the first one although it looks like it is networking related.
Assuming version 1.03.12, the second is while it is trying to initialise DNS resolution; it isn't one I remember seeing before.
 
I think we've long known that the Humax code isn't well tested (exhaustive testing is an extremely expensive process), and any unusual circumstances tend to land the execution into an undebugged section. Networking is one of those dodgy areas - it all works OK as long as the network traffic is perfect, but almost any hiccup can lead the code through an untested branch and sometimes crash. To test that would have required Humax to simulate every possible network fault. They would have ended up with a unit too expensive for the retail market. (That said, I don't know why they used new buggy code instead of importing well proven code - perhaps they just made a bad choice.)

Minimising this kind of crash means ensuring your home network is up to scratch - for example: my crashes reduced significantly after I updated the firmware in my HomePlugs (powerline networking), thus improving network reliability. However, it isn't practical to eliminate every possibility of a network communication error (some occur outside the local network), so one has to accept that there will be occasional crashes (unless you don't have your box connected to a network).

Some members here use a timeswitch to power-cycle their HDR-FOX once a day. That provides a hard reboot, so ensures a crash only lasts a maximum of 24 hours before normal service is resumed, even when unattended. If you go that way, I recommend you set the power-off to occur during a daily standby period.
 
af123 said:
These are both crashes caused by bugs in the Humax code
Click to expand...
A bit of research on the internet suggests that both bus errors and segmentation errors can also be caused by hardware faults. It's just possible that it isn't buggy Humax code but a bit of flakey hardware.
 
EEPhil said:
A bit of research on the internet suggests that both bus errors and segmentation errors can also be caused by hardware faults. It's just possible that it isn't buggy Humax code but a bit of flakey hardware.
Click to expand...
No, these are software faults. I can see in this example that it is accessing unmapped memory.
It's possible to track them down to the root cause, and create a patch to fix them, but it can take hours per bug and there are many.
 
EEPhil said:
A bit of research on the internet suggests that both bus errors and segmentation errors can also be caused by hardware faults. It's just possible that it isn't buggy Humax code but a bit of flakey hardware.
Click to expand...
Sorry, my reply yesterday was hurried and incomplete.
You're right, hardware faults in memory (CPU cache in particular) or in the memory management unit can cause errors like this too. However from the information provided above, I can see that these ones are software bugs.
 
Many thanks guys for this invaluable information. I will continue to monitor and hope that it doesn't escalate. Never had problems with my network before but worth investigating further.
 
You must log in or register to reply here.
Back
Top