gmane.comp.misc.nslu2.linux

Re: Catching SIGSEGV

clerew5 — 2012-05-21T09:43:23


--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, David Given <dg< at >...> wrote:

Yes, that is what I thought, and the thread in question was the only one allowed to see the signals (the prime purpose off that thread is to catch people who suddenly press buttons). But it seems that SIGSEGV (unless generated externally) is only sent to the thread it happened in, or maybe its parents.


Actually, it is doing better than I thought. Here is some actual output:

./heat(pthread_create+0x710)[0x9da0]
/lib/libc.so.6(__default_rt_sa_restorer_v2+0x0)[0x4010bcf0]
/lib/libc.so.6(_IO_printf+0x34)[0x40120dfc]
./heat[0x14a18]
./heat[0x17274]
./heat(pthread_create+0x680)[0x9d10]

The addresses within [...] are indeed the addresses of code being obeyed all down the stack. But [0x9da0] is NOT within pthread_create (nm shows it is actually within my handler). Likewise [0x9d10] is within 'main', and [0x14a18] and [0x17274] are at identifiable places which gave me the clue as to where the fault was happening (though the

Re: Re: Catching SIGSEGV

David Given — 2012-05-18T23:20:55

[...]

This is definitely getting out of my comfort zone (signals and threads
mix like oil and cats), but I was under the impression that outside
signals to sent to a single thread *at random* that had the signal
unblocked? So you control which thread you want to receive the signals
by blocking them from everywhere else.

[...]
[...]

I've tried the test program in the backtrace man page on my armhf box,
and it doesn't work. I'm afraid that it's possible that backtrace simply
doesn't work on ARM.


You may be treading on thin ice here. Depending on what causes the seg
fault, it's quite possible that the system will be in a bad state ---
for example, if you call fwrite(), and the buffer is unreadable, then
it's entirely likely that the signal will be thrown while it's in the
middle of modifying the stdio state. Which means that trying to use
stdio again will hang, crash, etc. The magic keyword to search for is
'async signal safe'.

(Related: there is a very limited list of operations that you can safely
do in

Re: Catching SIGSEGV

clerew5 — 2012-05-18T22:09:08


--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, David Given <dg< at >...> wrote:


Ah! I had thought that all signals would be passed to all threads (which is indeed the case for signals arising from outside).

Yes, I have now set up a sigaction-type handler in main(), and it seems to be inherited by processes created subsequently to that. It sort of works, but I need to know where the SIGSEGV came from, in order to know where to look for the bug. Here is my current handler:

void errHandler(int signum, siginfo_t *info, void *ptr) { 
        int count = backtrace( tracePtrs, 100 ); 
        backtrace_symbols_fd(tracePtrs, count, 2); 
        fatal("Heat failed with %s: si_code=%d", 
              strsignal(signum), info->si_code); 
} 

         errAction.sa_sigaction = errHandler;
        errAction.sa_flags = SA_SIGINFO;
       sigaction(SIGSEGV, &errAction, NULL);
        sigaction(SIGBUS, &errAction, NULL);
        sigaction(SIGILL, &errAction, NULL);
        sigaction(SIGFPE, &errAction, NULL);

Re: Catching SIGSEGV

David Given — 2012-05-17T22:12:18

[...]

I'm not quite sure what you're trying to do here --- AIUI sigwait()
blocks until a signal *for the blocked thread* is received, so no code
that can generate the signal will be run... (unless you send it manually
from another thread).

If you're trying to catch a signal thrown by code in a different thread,
then I don't think that will work.

The simplest approach is to just register a SIGSEGV signal handler in
the thread that's going to be doing the work. Then, when the signal is
thrown, your handler will run. If you want to do the work in a different
thread, then you'll need some sort of IPC between threads (but beware
that you can only run a small subset of functions safely from inside a
signal handler).

A more complicated and slower but much more flexible approach is to use
ptrace to monitor the running thread; when a signal is thrown, it will
be suspended and your monitor will be sent a message. It all depends
what you want to do.

(Also, check out libsigsegv: http://libsigsegv.sourceforge.net)

CPAN fix for perl for optware

markduncan72 — 2012-05-17T17:16:29

I have optware on my router with 32mb and I got perl but the module I wanted wasn't available via ipkg so I went to use CPAN to find it wouldn't work...
Even if I did configure it correctly (i'm 99% sure i did since i had expert help) it would have taken days to do anything as using swap made it slooooooow) I started off with this site http://www.nslu2-linux.org/wiki/HowTo/ConfigureCPAN and that didn't cut it.

I moved over to using cpanm - https://github.com/miyagawa/cpanminus
but that gave an error so i did this

https://github.com/shadowcat-mst/cpanminus/commit/9eba7dd0af9e63a4cadde8b0f5483a43a5e63deb **** credit goes to wtf911(myself) and mst*****

With that cpanm works good and you just need the proper ipkgs prior to using it...

i can't say what if all of these you need:

binutils
expat
glib
grep
gzip
less
libc6-unslung
libdb
libgcc
libxml2
lynx
man
ncftp
ncursesw
openssh
openssl-dev
readline
sqlite
tz
unslung-devel
unslung-feeds
update-modules
which
zlib

but on top of those you want:

tar
wget
make
i

Catching SIGSEGV

clerew5 — 2012-05-17T16:59:45

I am trying to trap a SIGSEGV (also SIGBUS, SIGILL and SIGFPE, but I have not even managed to generate those yet :-( ).

I can easily get the program to produce a message "Segmentation Violation" on stderr, but noway can I catch it before getting that message.

I have written
        sigemptyset(&set);
        sigaddset(&set, SIGUSR1);
        sigaddset(&set, SIGUSR2);
        sigaddset(&set, SIGTERM);
        sigaddset(&set, SIGINT);
        sigaddset(&set, SIGSEGV);
        sigaddset(&set, SIGBUS);
        sigaddset(&set, SIGILL);
        sigaddset(&set, SIGFPE);
        sigaddset(&set, SIGSYS); 
and I have created a pthread which contains
                sigwait(&set, &signal);
printf("Display signal %d\n", signal);
                switch (signal) {
                case SIGSEGV:
                case SIGBUS:
                case SIGILL:
                case SIGFPE:
                case SIGSYS:
                        fatal("Heat failed: %s", strerror(errno));
                case SIGTERM:
                c

I2C and kernel mutexes

clerew5 — 2012-05-17T10:49:13

Is the I2C implementation in Slugos5.3 based upon the i2c-dev.c and i2c-core.c and i2c-algo-bit.c Linux drivers?

I use the I2C_RDWR ioctl call to send a bunch of messages to the i2c bus. According to the source code of i2c_transfer in i2c-dev.c ( am looking at linux-2.6.21.7, but I don't suppose more recent linuces are much different), a kernel mutex is set whilst the whole bunch is sent, and thus the bunch can be regarded as an atomic action.

But what I am seeing does not support this view. I have a variety of devices on my i2c bus, including an ADC and an EEPROM. If I run two programs, one of which is polling the ADC vigorously, and one is reading lots of stuff from the EEPROM, then from time to time the ADC gets confused and returns results from the wrong channel (or which it has four). So it would seem that a bunch of messages for the EEPROM is getting co-mingled with a bunch of messages for the ADC, and according to my understanding of the kernel code, that should not happen.

Comments anyone?



----

Re: MySQL 4.1.22 build fails [SOLVED]

tals1975 — 2012-05-16T12:24:43

Fajar,

You were right...
Installation of gcc-c++ resolved the issue.

--
Regards,
Sergey

--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "tals1975" <tals1975< at >...> wrote:




------------------------------------

Re: MySQL 4.1.22 build fails

tals1975 — 2012-05-16T10:41:33

Fajar,

Thanks for your prompt reply. I think the problem is somewhere else, because g++ exists in the toolchain:

cs05q1armel/toolchain/arm-none-linux-gnueabi/gcc-2005q1-glibc-2.3.4/bin/arm-none-linux-gnueabi-g++

Please see this page:
http://bugs.mysql.com/bug.php?id=25576

I'm just trying to re-compile the package (needed for perl-dbd-mysql).
Someone has already compiled it successfully
(the package is available in the repository: http://ipkg.nslu2-linux.org/feeds/optware/cs05q1armel/cross/unstable/mysql_4.1.22-3_arm.ipk

The question is why I can not?

--
Sergey

--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Fajar A. Nugraha" <fajar< at >...> wrote:




------------------------------------

Re: MySQL 4.1.22 build fails

Fajar A. Nugraha — 2012-05-16T10:23:37

Isn't that last line obvious?

You should be able to work around that by installing whatever package
that provides g++.

MySQL 4.1.22 build fails

tals1975 — 2012-05-16T10:19:49

Hi All,

MySQL 4.1.22 build fails. Can someone have a look at this please?
Original mysql.mk was not modified.

Thank you in advance,
Sergey

source='my_new.cc' object='my_new.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
g++ -DDEFAULT_BASEDIR=\"/opt\" -DDATADIR="\"/opt/var\"" -DDEFAULT_CHARSET_HOME="\"/opt\"" -DSHAREDIR="\"/opt/share/mysql\"" -DHAVE_CONFIG_H -I. -I. -I.. -I../zlib -I../include -I../include -I.    -O -DDBUG_OFF    -c -o my_new.o my_new.cc
../depcomp: line 512: exec: g++: not found
make[4]: *** [my_new.o] Error 127
make[4]: Leaving directory `/tmp/_NEW_optware/optware/host/builds/mysql/mysys'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/_NEW_optware/optware/host/builds/mysql'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/_NEW_optware/optware/host/builds/mysql'
make[1]: *** [/tmp/_NEW_optware/optware/cs05q1armel/host/builds/mysql/.built] Error 2
make[1]: Leaving directory `/tmp/_NEW_optware/optware/cs05q1armel'
make: *** [/tmp/_NEW_optwar

LogitechMediaServer_v7.7.2 package request

tals1975 — 2012-05-14T15:26:23

Hi ALL!

Can someone would be so kind to prepare LogitechMediaServer_v7.7.2 for optware please? However, it is a big piece of job :)

http://downloads.slimdevices.com/LogitechMediaServer_v7.7.2/
http://svn.slimdevices.com/repos/slim/7.7/trunk/vendor/CPAN/

LogitechMediaServer_v7.7.2 supports more players and file formats in comparison with squeezecenter - 7.3.3 supported by optware.

Thank you very much in advance.
Sergey

P.S. I've tried to compile all necessary packages for LogitechMediaServer_v7.7.2. Unfortunately, stuck with libmediascan-0.1:

1] ./slimserver.pl --d_startup
Can't locate loadable object for module Media::Scan in < at >INC


2] (ffmpeg, libexif, libjpeg, libpng, giflib, libbdb are already in stage)


libtool: compile:  /tmp/optware/cs05q1armel/toolchain/arm-none-linux-gnueabi/gcc-2005q1-glibc-2.3.4/bin/arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -I/tmp/optware/cs05q1armel/staging/opt/include -Wall -I../include -I/tmp/optware/cs05q1armel/staging/opt/include -g -O2 -MT libmedias

Re: perl-dbd-sqlite make file update request [SOLVED]

tals1975 — 2012-05-11T07:46:10

Thank you!

SVN updated successfully.
I was able to compile and install perl-dbd-sqlite v.1.34_01

Regaeds,
Sergey



--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "tals1975" <tals1975< at >...> wrote:




------------------------------------

Re: perl-dbd-sqlite make file update request

tals1975 — 2012-05-11T07:21:03

Thank you for building and uploading of the new version.

Unfortunately, slimserver which I'm trying to start requires version 1.34_1:
./slimserver.pl --d_server
Your locale was detected as C, you may have problems with non-Latin filenames.  Consider changing your LANG variable to the correct locale, i.e. en_US.utf8
DBD::SQLite object version 1.35 does not match bootstrap parameter 1.34_01 at /opt/lib/perl5/5.10.0/arm-linux/DynaLoader.pm line 226.
Compilation failed in require at /root/_test/logitechmediaserver-7.7.2-33893-noCPAN/Slim/Utils/DbCache.pm line 11.


Is it possible to upload updated perl-dbd-sqlite.mk file so I can try to compile it myself?

Thank you,
Sergey

--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "tals1975" <tals1975< at >...> wrote:




------------------------------------

perl-dbd-sqlite make file update request

tals1975 — 2012-05-10T15:52:23

Hi All,

Please can someone update the following make file?

perl-dbd-sqlite to version 1.35


Unable to build the package: perl-dbd-sqlite due the following problem:


DBI 1.57 is required to configure this module; please install it or upgrade your CPAN/CPANPLUS shell.


However, perl-dbi v.1.620 is in stage

Thank you,
Sergey



------------------------------------

Re: apache - openssl installation (solved)

floh0033 — 2012-05-01T07:36:54


--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Brian" <b88zhou< at >...> wrote:

Thanks Brian !
seems it is working ...




------------------------------------

Re: apache - openssl installation

Brian — 2012-04-30T21:49:54

The package has been rebuilt and the latest version is 0.9.7m-6. Please do "ipkg update" and retry.

-Brian

--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "floh0033" <mario.althammer< at >...> wrote:




------------------------------------

Re: apache - openssl installation

floh0033 — 2012-04-30T20:06:01


--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Brian" <b88zhou< at >...> wrote:

Thanks for your response

Still the same problem this time...

Installing openssl (0.9.7m-5) to root...
Downloading http://ipkg.nslu2-linux.org/feeds/optware/nslu2/cross/stable/openssl_0.9.7m-5_armeb.ipk
wget: server returned error 404: HTTP/1.1 404 Not Found
Nothing to be done





------------------------------------

ipkg update reports "file too short"

theschles — 2012-04-30T18:52:41

Hi all,

I have a GoFlex Home, which is based upon the OpenStora system, which uses ipkg
for package management:
http://www.openstora.com/wiki/index.php?title=Getting_Started#Preparing_to_insta\
ll_software_and_checking_free_space

So I followed the instructions for moving /opt (I moved it to /mnt/eSata/opt)
and have been installing packages.

I cancelled an install process of ipkg and now it reports:

bash-3.2# /opt/bin/ipkg update
/opt/bin/ipkg: error while loading shared libraries: /opt/lib/libipkg.so.0: file
too short

The only way to get around this seems to be a reinstall of ipkg. That's
annoying...

Help?

- Phil


PS here is the results of running 'df':

bash-3.2# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 212M 196M 16M 93% /
ubi0:rootfs 212M 196M 16M 93% /
none 62M 32K 62M 1% /dev
nodev 62M 36M 26M 59% /var/log
nodev 62M 480K 61M 1% /mnt/tmpfs
nodev 62M 24K 62M 1% /var/lib/php/session
nodev 62M 480K 61M 1% /tmp
nodev 62M 480K 61M 1% /var/run
nodev 62M 480K 61M 1% /var/cache
nodev 62M 48

Re: apache - openssl installation

Brian — 2012-04-30T14:38:51

Should be fixed now.

-Brian

--- In nslu2-linux-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "floh0033" <mario.althammer< at >...> wrote:




------------------------------------

apache - openssl installation

floh0033 — 2012-04-29T19:03:05

an error occures during the apache installation on my slug (unslung 6.8)
apache needs  openssl for the install, but the link will be no more present

please could you help me ?



------------------------------------