[SOLVED] Strange Segmentation Fault

mr.simo · 10-23-2015, 11:40 AM

Hi all,

I am doing the porting of a new distro on my embedded platform, and I am experiencing problems while running a binary file on the new distro.

On the old one, an ngstrom with kernel 2.6.34 it was running without any problem.

On this new distro, yocto-gumstix, with kernel 3.18.18, gcc version 4.9.2, the program (compiled on the same machine) falls into Segmentation Fault upon execution..

gdb can read the source code of the file, but executing it (with the required arguments) and making a backtrace gives:

Code:

(gdb) r 1000
Starting program: /home/user/packages/tsc/tsc 1000
Cannot access memory at address 0x0
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt 
#0  0x00000000 in ?? ()
#1  0xb68e9734 in __pthread_initialize_minimal () from /lib/libpthread.so.0
Cannot access memory at address 0x0
#2  0xb68e8d04 in ?? () from /lib/libpthread.so.0
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

So it seems /lib/libpthread.so.0 gives problems, but right now I have no idea about how to fix this issue...

Any suggestion ?

Regards

Rinndalir · 10-23-2015, 01:14 PM

This seems relevant:

Quote:

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

What does this tell you?

Code:

ldd program

Have you tried making a static program?

Also try creating a smaller, simpler program to reduce the problem space. This may narrow it down to the actual problem.

mr.simo · 10-23-2015, 05:06 PM

Hi, the first message appears also when I am debugging a working program.

Static program also fails.. The program uses proprietary non opem source libs so I think the problem comes from there, because a simple program using pthreads, works perfectly..

The libraries are all present. From the output of ldd no one is missing..

debguy · 10-23-2015, 09:35 PM

ldd won't tell the full story

gdeptrace-0.5.7/SCRIPTS/libdeps can trace more but requires experience

$ objdump -x -a progname

for each libname there, objdump it as well, recursively

manually insure each lib is right version: unfortunately you many not be able to. there are hacks releasing libs a small minor version apart that are incompatible with prev. version (in unix wares that are supposed to be bullet proof no less). another problem is they tend to install ontop "clobber" (by design, minor should be ok to do that: but it isn't, which is why some attack that way) which makes it very difficult for the casual developer to compile anything.

more than likely "usually" you'll find it's your own fault. maybe in /usr/include/xx you'll have libpthread.h of wrong version, or /usr/lib/libpthread.so point to wrong version of pthread

debguy · 10-23-2015, 09:42 PM

> warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

you should be aware google + redhat + others have been hacking gcc and linux distros so that POTENTIALLY ...

your machine is open to them for "phoning home" and then "remote debugging" before you even get a login prompt

... just so you know.

debguy · 10-23-2015, 09:44 PM

you should also know that it isn't "the linux community" doing it! it's their competitors (ex (unproven?) possibly microsoft workers in china owrking on usa grant funds - or anyone) who pose as contributors doing it.

Rinndalir · 10-24-2015, 12:08 PM

Quote:

Originally Posted by mr.simo

Static program also fails.. The program uses proprietary non opem source libs so I think the problem comes from there, because a simple program using pthreads, works perfectly..

At least you know where to start looking further. Have you used the libs before in working programs that you made?

mr.simo · 10-25-2015, 08:00 AM

Quote:

Have you used the libs before in working programs that you made?

Yes. This program won't work without these libraries, it always used them.

I compiled the example for http://www.yolinux.com/TUTORIALS/Lin...xThreads.html:

Code:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

void *print_message_function( void *ptr );

int main()
{
     pthread_t thread1, thread2;
     const char *message1 = "Thread 1";
     const char *message2 = "Thread 2";
     int  iret1, iret2;

    /* Create independent threads each of which will execute function */

     iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1);
     if(iret1)
     {
         fprintf(stderr,"Error - pthread_create() return code: d\n",iret1);
         exit(EXIT_FAILURE);
     }

     iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2);
     if(iret2)
     {
         fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2);
         exit(EXIT_FAILURE);
     }

     printf("pthread_create() for thread 1 returns: %d\n",iret1);
     printf("pthread_create() for thread 2 returns: %d\n",iret2);

     /* Wait till threads are complete before main continues. Unless we  */
     /* wait we run the risk of executing an exit which will terminate   */
     /* the process and all threads before the threads have completed.   */

     pthread_join( thread1, NULL);
     pthread_join( thread2, NULL); 

     exit(EXIT_SUCCESS);
}

void *print_message_function( void *ptr )
{
     char *message;
     message = (char *) ptr;
     printf("%s \n", message);
}

and it works perfectly. Tomorrow I will try to use these libraries in this example, or making a mini-program which uses them.

I will update the thred.

Simon

mr.simo · 10-26-2015, 05:22 AM

I finally solved changing the order of the flags for dynamic libraries during compilation.

It was (omitting flags for external proprietary libs):

Code:

arm-poky-linux-gnueabi-g++ file0.cc file1.cc -o binaryfile -lm -lpthread -ldl -lrt -std=c++11

Now is:

Code:

arm-poky-linux-gnueabi-g++ -lm -lpthread -ldl -lrt -std=c++1 file0.cc file1.cc -o binaryfile

it works.. gcc version is 4.9.2.

Simon

pan64 · 10-26-2015, 06:46 AM

you should not use -lpthread but -pthread (without l) in general and should be used before almost any other flags (especially before your .cc files). -l<libs> should be moved at the end of the command.