Segfault with signals

[prpr]

Can anyone advise on how to pin the blame for this simple test-case, which gives a Segmentation error on return from main():

#include <stdio.h>
#include <signal.h>

void signal_handler(int signum)
{
}

int main(int argc, char *argv[])
{
        struct sigaction sigact;

        sigact.sa_handler = signal_handler;
        sigemptyset(&sigact.sa_mask);
        sigact.sa_flags = 0;
        sigaction(SIGTERM, &sigact, NULL);
        return 0;
}

I have no idea with gdb I'm afraid.

 

[/df]

Definitely. The implementation of sigemptyset() doesn't match the size of the signal block that's actually used. The uClibc library thinks there are 1024 signal bits (matches glibc), but the headers think there are 128 (matches the Linux MIPS architecture).

Any on-box build that uses sig*set() will crash, unless you override the implementations in libuClibc.so, say linking with a sigset.o built from the sigset.c in the referenced post ahead of the implicit -luClibc.

 

[/df]

Apparently the broken C library /lib/libuClibc-0.9.29.so in CF is the original from the Humax firmware (HDR file date: May 8 2009 20:10:59.000 +0100).

I've now recovered the configuration data for the library build from the Humax open source download, so it might be possible to rebuild the library, given a cross-compilation environment with more space than I have just now. The configuration data doesn't include the number of signals, so that must have been a defect in the Humax build environment.

However the settop binary is linked to sigemptyset(). As we don't have evidence of it crashing there, it must have been built with the same faulty headers: reducing the size of sigset_t used by libuClibc would have meant that it wouldn't find subsequent members of a struct sigaction at the offset where the settop binary put them, except that, as below, it's actually the last member.

So the solutions for now are: to supply a sigset.o as suggested, or to change the headers to make _NSIG 1024.

 

[prpr]

Thanks for the pointer (!). I had a dim recollection of something like this before but didn't try searching for the obvious.
It's actually _SIGSET_NWORDS that needs to change:

humax /mnt/hd2/mod/include/bits # diff sigset.h~ sigset.h
--- sigset.h~
+++ sigset.h
@@ -33,7 +33,7 @@
  * BTW, struct sigaction is also the same on kernel and userspace side..
  */
 #if defined(__mips__)
-# define _SIGSET_NWORDS        (128 / (8 * sizeof (unsigned long)))
+# define _SIGSET_NWORDS        (1024 / (8 * sizeof (unsigned long)))
 #else
 # define _SIGSET_NWORDS        (64 / (8 * sizeof (unsigned long)))
 #endif

This fixes the problem without any other messing about.

 

[/df]

Except that your binary no longer conforms to the Linux MIPS ABI, if you cared. As the comment above the modified lines quoted above says, "In uclibc, kernel and userspace sigset_t is always the same."

The Humax kernel build doesn't use sigset.h; it uses .../include/asm-mips/signal.h, which has:

#define _NSIG         128
#define _NSIG_BPW     (sizeof(unsigned long) * 8)
#define _NSIG_WORDS   (_NSIG / _NSIG_BPW)

typedef struct {
      unsigned long sig[_NSIG_WORDS];
} sigset_t;

Fortunately the mask member is last in struct sigaction, so faulty user-mode programs (and programs compiled with the modified sigset.h as above) just pass a memory block whose last 112 bytes are ignored. This would have been a problem had sigemptyset() been implemented in the kernel.

 

[prpr]

The link in post #2 just generates this for me:

"
The site at https://hummy.tv/forum/threads/advert-commercial-removing.1239/post-121705 has experienced a network protocol violation that cannot be repaired.

The page you are trying to view cannot be shown because an error in the data transmission was detected.

Please contact the web site owners to inform them of this problem
"

Anyone else?

 

[trog]

The link in post #2 just generates this for me:

"
The site at https://hummy.tv/forum/threads/advert-commercial-removing.1239/post-121705 has experienced a network protocol violation that cannot be repaired.

The page you are trying to view cannot be shown because an error in the data transmission was detected.

Please contact the web site owners to inform them of this problem
"

Anyone else?

Opera gives me This site can't be reached ERR_FAILED
A search of advert commercial removing shows that Brian moved the original thread but both come up as ERR_FAILED. It appears that it may be a problem referred to as far back as 2012 as explained here in 2018 https://hummy.tv/forum/threads/locked-thread.8655/#post-121750 Having advert in the title screws things up, something is taking Ad blocking a little bit too far

 

[Black Hole]

The link in post #2 just generates this for me:

There is a coincidental timing with this:

I acquired my ninth Foxsat HDR yesterday and commenced to kit it out with the usual Raydons and HD encryption crack etc. After this I tried to install the Web-IF on the box usng the Box homepage shown in Firefox. To my dismay, it kept returning a site not found error. ie;- "The online repository hosted at 'hpkg.tv' is unreachable." I kept trying but it would not access the repository site. I then found the web-IF opk file from the download pages and added it to a blank USB flashdrive but that didn't work either. Can someone tell me why it will not access the site? Or why I can't install the web-IF opk from a flashdrive? Never had any trouble before with my previous 8 boxes. Thanks.

Could it be a server problem?

 

[/df]

Perhaps something has been changed but https://hummy.tv/forum/threads/advert-commercial-removing.1239/post-121705 Works For Me.

 

[prpr]

It's AdblockPlus that's causing it, but it's a very confusing message.

 

[prpr]

Anyway, back to the original problem.
I have managed to do (another!) patch to the uClibc library to fix this, so hopefully it will make it into the next CF.

 

[trog]

" something is taking Ad blocking a little bit too far " It appears that I was correct, no need to thank me for my effort to assist.