[gelöst] probleme mit pthreads

Vlad_Tepesch

Neuer User
Mitglied seit
2 Jun 2007
Beiträge
60
Punkte für Reaktionen
0
Punkte
0
Hi,
Ich bin grad ein wenig am verzweifeln an threadprogrammierung für eine
Fritzbox(7170)-Anwendung.

Ich habe folgenden Code:


hier mein soweit abgespeckter code, dass sich es nachvollziehen lässt:
Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <inttypes.h>
#include <stdbool.h>

#include <time.h>
#include <pthread.h>


#ifdef _WIN32
#  include <windows.h>
#  define sleepMs(x) do{Sleep(x);}while(0)
#else
#  include <unistd.h>
static void sleepMs(uint32_t ms)
{
  struct timespec sleepTime;
  struct timespec remainingSleepTime;
  sleepTime.tv_sec  = ms/1000;
  sleepTime.tv_nsec = (ms%1000)*1000000;
  nanosleep(&sleepTime,&remainingSleepTime);
}
#endif





void* receiveThread(void* arg)
{
  while(23){
    printf("iam the thread loop\n");
    sleepMs(2000);
  }
}

int main(void)
{
  pthread_t thread = {0};
  int rc;
  printf("enter main\n");

  rc = pthread_create( &thread, NULL, &receiveThread, NULL);
  if(rc){
   perror("could not create THread\n");
  }
  printf("started thread\n");

  while(1)
  {
    printf("iam the main loop\n");
    sleepMs(1000);
  }
  return EXIT_SUCCESS;
}


unter windows läuft er wie erwartet.
ich benutze visual studio 2008 express mit einer windows pthread
bibliothek (die leider die sleep funktionen nicht kennt, deswegen die
unterscheidung)



auf der Fritzbox läuft das ganze dann so, dass ich nur die ausschriften
der main-loop bekomme.

root@fritz:/var/media/ftp/uStor11# ./helloworld
enter main
started thread
iam the main loop
iam the main loop
iam the main loop
iam the main loop

kann mir hier jemand weiterhelfen?


Ich hatte das zuerst hier (https://www.mikrocontroller.net/topic/248654#2548102) gepostet , da ich da normalerweise unterwegs bin, aber hier sind eher die Spezialisten für die Fritzbox versammelt ;)

unter einem normalen Linux scheint das ganze auch zu laufen,

Tim T. schrieb im Beitrag https://www.mikrocontroller.net/topic/248654#2548129 :
> Könnte ein Problem im Threading des Linuxkernels auf deiner Fritzbox
> sein, auf 3 verschiedenen Linuxsystemen (Desktop, Atom, NAS) lies sich
> dein Code wie zu erwarten Ausführen.

MfG
Vlad
 
Zuletzt bearbeitet:
auf der Fritzbox läuft das ganze dann so, dass ich nur die ausschriften
der main-loop bekomme.

root@fritz:/var/media/ftp/uStor11# ./helloworld
enter main
started thread
iam the main loop
iam the main loop
iam the main loop
iam the main loop

kann mir hier jemand weiterhelfen?
Ich bekomme mehr auf meiner FB:
Code:
root@fritz:/var/media/ftp/uStor01/archiv#[COLOR=red] ldd ./testx[/COLOR]
        [COLOR=red]libpthread.so.0 => /lib/libpthread.so.0 (0x2aabe000)[/COLOR]
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aae1000)
        libc.so.0 => /lib/libc.so.0 (0x2aaff000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)

root@fritz:/var/media/ftp/uStor01/archiv# [COLOR=red]./testx[/COLOR]
enter main
started thread
iam the main loop
[COLOR=red]iam the thread loop[/COLOR]
Wie schaut dein Makefile aus?
 
Keine Ahnung, was bei Dir das Problem ist.

Ich habe das Programm von Dir genommen, übersetzt mit
Code:
mipsel-linux-gcc -o helloworldt helloworld.c -lpthread
Es kommt das heraus, was man erwarten kann:
Code:
# ./helloworld
enter main
started thread
iam the main loop
iam the thread loop
iam the main loop
iam the thread loop
iam the main loop
iam the main loop
iam the thread loop
iam the main loop
iam the main loop
iam the thread loop
iam the main loop
iam the main loop
iam the thread loop
iam the main loop
iam the main loop
 
@Vlad_Tepesch
Lt. den Beiträgen im anderen Forum, hast Du mit "-lpthreads" statt mit "-lpthread" versucht zu kompilieren. Hast Du keine Fehlermeldung bekommen:
Code:
...
mipsel-linux-uclibc/bin/ld: [COLOR=red]cannot find -lpthreads[/COLOR]
collect2: ld returned 1 exit status
...
oder
Code:
...
/tmp/ccYcqTK1.o: In function `main':
testx.c:(.text+0xa0): undefined reference to `pthread_create'
collect2: ld returned 1 exit status
make[1]: *** [testx] Fehler 1
...
Wenn Du es genau wissen willst, dann kannst Du im make-Verzeichnis immer nachschauen:
Code:
find [COLOR=red]make[/COLOR] -iname '*.mk' -exec grep -H "[COLOR=blue]lpthread[/COLOR]" {} \;
Code:
find [COLOR=red]make[/COLOR] -iname '*.mk' -exec grep -H "lpthread[COLOR=red][B]s[/B][/COLOR]" {} \;


EDIT:


Sehr schön, wie überzeugt der Moderator von den Experten in seinem Forum ist:;)
Autor: Jörg Wunsch (dl8dtl) (Moderator)
Datum: 14.02.2012 15:38
...
Die Linux-Experten (die du für die Beantwortung dieser Frage brauchst)
wirst du aber ohnehin eher hier in diesem Forum finden, auch wenn deine
Zielplattform ein MIPS ist.
 
Zuletzt bearbeitet:
hmm, bei dir gehts also :confused:

Sehr schön, wie überzeugt der Moderator von den Experten in seinem Forum ist:;)
Was er meinte, war aber das Subforum PC-Programmierung, weil ich es vorher unter µC und Elektronik gepostet hatte, und gefragt hatte, warum es verschoben wurde.
Das war nicht gegen das IPphoneforum gedacht, falls du das so aufgefasst hast.



Wie schaut dein Makefile aus?
@Vlad_Tepesch
Lt. den Beiträgen im anderen Forum, hast Du mit "-lpthreads" statt mit "-lpthread" versucht zu kompilieren. Hast Du keine Fehlermeldung bekommen:

Das war aus dem Gedächtnis, wie ich auch angedeutet hatte.

hier mein MAkefile:

Code:
TOOLCHAINBASE=/home/freetz/freetz-trunk/toolchain/build/mipsel_gcc-4.5.3_uClibc-0.9.29/mipsel-linux-uclibc
INCLUDEPATH=$(TOOLCHAINBASE)/include
LIBPATH=$(TOOLCHAINBASE)/lib
BINPATH=$(TOOLCHAINBASE)/bin
TOOLPREFIX=/mipsel-linux-

###############################################################
#####
##### Compiler, Linker and Tools
#####
###############################################################

CC=$(BINPATH)$(TOOLPREFIX)gcc
CPP=$(BINPATH)$(TOOLPREFIX)g++
AS=$(BINPATH)$(TOOLPREFIX)as
LD=$(BINPATH)$(TOOLPREFIX)gcc
OC=$(BINPATH)$(TOOLPREFIX)objcopy
OD=$(BINPATH)$(TOOLPREFIX)objdump

CPUFLAGS=
OPTFLAGS=-Os
#OPTFLAGS=

CFLAGS=$(CPUFLAGS) -D_REENTRANT -c -Wall -I$(INCLUDEPATH)
ASFLAGS=$(CPUFLAGS) -D_REENTRANT -D --gstabs
ROMLDFLAGS=-lc -lpthread -s -Wl,-warn-common
THUMBFLAGS=

PROJECT=helloworld

all: $(PROJECT)

$(PROJECT): main.o socketlayer_linux.o
	$(LD) $(ROMLDFLAGS) -o $(PROJECT) main.o socketlayer_linux.o

main.o: main.c
	$(CC) $(CFLAGS) $(THUMBFLAGS) -L $(LIBPATH) -o main.o main.c
  
socketlayer_linux.o: socketAbstractionLayer/socketlayer_linux.c
	$(CC) $(CFLAGS) $(THUMBFLAGS) -L $(LIBPATH) -c $<

  
clean:
	$(RM) -v $(PROJECT) *.o *.elf *.bin *.hex *~

### EOF
 
Zuletzt bearbeitet:
was mich wundert, ist, dass nach dem Starten von der Datei ps drei Prozesse anzeigt.
ldd liefert folgendes:
Code:
root@fritz:/var/media/ftp/uStor11# ./ldd helloworld
        libc.so.0 => /lib/libc.so.0 (0x2aabe000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2ab39000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ab5c000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)
 
Versuch mal mit diesem Makefile:
Code:
TOOLCHAINBASE=/home/freetz/freetz-trunk/toolchain/build/mipsel_gcc-4.5.3_uClibc-0.9.29/mipsel-linux-uclibc
INCLUDEPATH=$(TOOLCHAINBASE)/include
LIBPATH=$(TOOLCHAINBASE)/lib
BINPATH=$(TOOLCHAINBASE)/bin
TOOLPREFIX=/mipsel-linux-

###############################################################
#####
##### Compiler, Linker and Tools
#####
###############################################################

CC=$(BINPATH)$(TOOLPREFIX)gcc
CPP=$(BINPATH)$(TOOLPREFIX)g++
AS=$(BINPATH)$(TOOLPREFIX)as
LD=$(BINPATH)$(TOOLPREFIX)gcc
OC=$(BINPATH)$(TOOLPREFIX)objcopy
OD=$(BINPATH)$(TOOLPREFIX)objdump

CPUFLAGS=
OPTFLAGS=-Os
#OPTFLAGS=

CFLAGS=-march=4kc -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
ASFLAGS=$(CPUFLAGS) -D_REENTRANT -D --gstabs
ROMLDFLAGS=-lc -lpthread -s -Wl,-warn-common
THUMBFLAGS=

PROJECT=helloworld

all: $(PROJECT)

#$(PROJECT): main.o socketlayer_linux.o
#    $(LD) $(ROMLDFLAGS) -o $(PROJECT) main.o socketlayer_linux.o

helloworld: helloworld.c
    $(CC) $(CFLAGS) -o helloworld helloworld.c -lpthread
  
#socketlayer_linux.o: socketAbstractionLayer/socketlayer_linux.c
#    $(CC) $(CFLAGS) $(THUMBFLAGS) -L $(LIBPATH) -c $<

  
clean:
    $(RM) -v $(PROJECT) *.o *.elf *.bin *.hex *~

### EOF
 
Woran lag es jetzt genau?
Keine Ahnung:
Code:
$(PROJECT): main.o socketlayer_linux.o
    $(LD) $(ROMLDFLAGS) -o $(PROJECT) main.o socketlayer_linux.o

main.o: main.c
    $(CC) $(CFLAGS) $(THUMBFLAGS) -L $(LIBPATH) -o main.o main.c
Deine Makefile hat zusätzliche source Dateien: "main.c socketlayer_linux.c".
 
Keine Ahnung:
Deine Makefile hat zusätzliche source Dateien:
an denen lag es nicht, die hab ich jetzt auch wieder drin (war aber für den Besipielcode unwichtig)


Muss irgendwas mit den compiler flags zu tun haben

hab jetzt folgendes draus gemacht:
Code:
TOOLCHAINBASE=/home/freetz/freetz-trunk/toolchain/build/mipsel_gcc-4.5.3_uClibc-0.9.29/mipsel-linux-uclibc
BINPATH=$(TOOLCHAINBASE)/bin
TOOLPREFIX=/mipsel-linux-

PROJECT=helloworld

SRC_FILES += main.c
SRC_FILES += socketAbstractionLayer/socketlayer_linux.c

LIBS=-lpthread 

###############################################################
#####
##### Compiler, Linker and Tools
#####
###############################################################

CC=$(BINPATH)$(TOOLPREFIX)gcc
CPP=$(BINPATH)$(TOOLPREFIX)g++
AS=$(BINPATH)$(TOOLPREFIX)as
LD=$(BINPATH)$(TOOLPREFIX)gcc
OC=$(BINPATH)$(TOOLPREFIX)objcopy
OD=$(BINPATH)$(TOOLPREFIX)objdump


CFLAGS=-march=4kc -Os -pipe -Wall -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

all: 
	$(CC) $(CFLAGS) -o $(PROJECT) $(SRC_FILES) $(LIBS)

  
clean:
	$(RM) -v $(PROJECT) *.o *.elf *.bin *.hex *~

### EOF
 
Zuletzt bearbeitet:
M. E. ist es am einfachsten mit einem Freetz-Paket, etwas für die Box zu kompilieren. Da hat man auch die Übersicht betr. Abhängigkeiten zu compile- und run-time.
 
Schau Dir mal die Optionen an, die in beiden Fällen beim Aufruf verwendet werden. Ändere dann eine nach der anderen, bis sich das Verhalten ändert.

Das hätte ich auch noch gemacht. hätte ja sein können, dass du sofort weißt, woran das lag, oder bzw an welchen optionen es auf keinen Fall gelegen haben kann

edit:
ich vermute ganz stark das -march
 
Zuletzt bearbeitet:
Ich vermute ganz stark, dass es nicht das -march ist. Bei mir hat es auch ohne jegliche Optionen funktioniert, nur mit der Library, wie oben gezeigt.

Du kannst mal probieren, ob das bei Dir auch so ist. Wenn ja, hast Du auf jeden Fall weniger Unterschiede und solltest leichter herausfinden können, woran es liegt.
 
Das hätte ich auch noch gemacht. hätte ja sein können, dass du sofort weißt, woran das lag, oder bzw an welchen optionen es auf keinen Fall gelegen haben kann

edit:
ich vermute ganz stark das -march
Ich denke es liegt an deinem Makefile, d. h. wie Du kompilierst und linkst. Dein Makefile macht z. B. Folgendes:
Code:
# ./freetz_cc [COLOR=red]-D_REENTRANT -c -Wall -o helloworld.o helloworld.c[/COLOR]
Code:
# ./freetz_cc [COLOR=red]-lc -lpthread -s -Wl,-warn-common -o helloworld helloworld.o[/COLOR]
Und das ist das binary:
Code:
# [COLOR=red]objdump -t ./helloworld[/COLOR]

./helloworld:     file format elf32-tradlittlemips

SYMBOL TABLE:
[COLOR=red]no symbols[/COLOR]
Das hier funktioniert:
Code:
# ./freetz_cc -o helloworld3 helloworld.c -lpthread
Code:
# [COLOR=red]objdump -t ./helloworld3[/COLOR]

./helloworld3:     file format elf32-tradlittlemips

SYMBOL TABLE:
00400134 l    d  .interp        00000000              .interp
00400148 l    d  .reginfo       00000000              .reginfo
00400160 l    d  .dynamic       00000000              .dynamic
00400268 l    d  .hash  00000000              .hash
00400308 l    d  .dynsym        00000000              .dynsym
00400458 l    d  .dynstr        00000000              .dynstr
0040056e l    d  .gnu.version   00000000              .gnu.version
00400598 l    d  .gnu.version_r 00000000              .gnu.version_r
004005b8 l    d  .rel.plt       00000000              .rel.plt
004005f0 l    d  .init  00000000              .init
00400640 l    d  .plt   00000000              .plt
004006d0 l    d  .text  00000000              .text
00400a00 l    d  .fini  00000000              .fini
00400a40 l    d  .rodata        00000000              .rodata
00400aa0 l    d  .eh_frame      00000000              .eh_frame
00410aa4 l    d  .ctors 00000000              .ctors
00410aac l    d  .dtors 00000000              .dtors
00410ab4 l    d  .jcr   00000000              .jcr
00410ac0 l    d  .data  00000000              .data
00410ad0 l    d  .rld_map       00000000              .rld_map
00410ad4 l    d  .got.plt       00000000              .got.plt
00410b00 l    d  .got   00000000              .got
00410b08 l    d  .sdata 00000000              .sdata
00410b10 l    d  .bss   00000000              .bss
00000000 l    d  .comment       00000000              .comment
00000000 l    d  .pdr   00000000              .pdr
00000000 l    d  .gnu.attributes        00000000              .gnu.attributes
00410b30 l    d  .mdebug.abi32  00000000              .mdebug.abi32
00000000 l    df *ABS*  00000000              initfini.c
00000000 l    df *ABS*  00000000              crtstuff.c
00410aa4 l     O .ctors 00000000              __CTOR_LIST__
00410aac l     O .dtors 00000000              __DTOR_LIST__
00400aa0 l     O .eh_frame      00000000              __EH_FRAME_BEGIN__
00410ab4 l     O .jcr   00000000              __JCR_LIST__
00400720 l     F .text  00000000              __do_global_dtors_aux
00410b10 l     O .bss   00000001              completed.5168
00410b14 l     O .bss   00000004              dtor_idx.5170
004007cc l     F .text  00000000              frame_dummy
00410b18 l     O .bss   00000018              object.5180
00000000 l    df *ABS*  00000000              crtstuff.c
00410aa8 l     O .ctors 00000000              __CTOR_END__
00400aa0 l     O .eh_frame      00000000              __FRAME_END__
00410ab4 l     O .jcr   00000000              __JCR_END__
004009b0 l     F .text  00000000              __do_global_ctors_aux
00000000 l    df *ABS*  00000000              initfini.c
00400718 l       .text  00000000              hlt
00000000 l    df *ABS*  00000000              helloworld.c
00400830 l     F .text  000000a4              sleepMs
00400160 l     O .dynamic       00000000              _DYNAMIC
00410b08 l     O .sdata 00000000              __dso_handle
00400640 l     O .plt   00000000              _PROCEDURE_LINKAGE_TABLE_
004008d4 g     F .text  00000038              receiveThread
00410ac0 g       .data  00000000              _fdata
00000000       O *UND*  00000000              _gp_disp
00000000       F *UND*  00000000              pthread_create
00000001 g    d  *ABS*  00000000              _DYNAMIC_LINKING
00400670  w    F *UND*  00000000              0x08 __register_frame_info@@GLIBC_2.0
00418af0 g       *ABS*  00000000              _gp
00000000       F *UND*  00000000              perror
00410ab0 g     O .dtors 00000000              .hidden __DTOR_END__
00000000       F *UND*  00000000              puts
004005f0 g     F .init  0000001c              _init
00000000       F *UND*  00000000              nanosleep
004006b0  w    F *UND*  00000000              0x08 __deregister_frame_info@@GLIBC_2.0
004006d0 g     F .text  00000050              __start
004006d0 g       .text  00000000              _ftext
00410ad0 g     O .rld_map       00000000              __RLD_MAP
00000000       F *UND*  00000000              __uClibc_main
00410b0c g       *ABS*  00000000              __bss_start
0040090c g     F .text  000000a4              main
00410ac0  w    O .data  00000000              data_start
00400a00 g     F .fini  0000001c              _fini
00410b0c g       *ABS*  00000000              _edata
00410b00 g     O *ABS*  00000000              _GLOBAL_OFFSET_TABLE_
00410b30 g       *ABS*  00000000              _end
00410ac0 g     O .data  00000000              __data_start
00000000  w      *UND*  00000000              _Jv_RegisterClasses
00410b0c g       *ABS*  00000000              _fbss
 
Es ist das Linken der libc, das die unerwünschte Ausgabe verursacht:
Code:
./freetz_cc [B][COLOR=red]-lc[/COLOR][/B] -lpthread -o helloworld7 helloworld.o
Code:
root@fritz:/var/media/ftp/uStor01/archiv# ./helloworld7
enter main
started thread
iam the main loop
iam the main loop
iam the main loop
iam the main loop
iam the main loop
iam the main loop
iam the main loop
... ohne libc:
Code:
./freetz_cc -lpthread -o helloworld6 helloworld.o
Code:
root@fritz:/var/media/ftp/uStor01/archiv# ./helloworld6
enter main
started thread
iam the main loop
iam the thread loop
iam the main loop
iam the thread loop
iam the main loop
iam the main loop
iam the thread loop
iam the main loop
iam the main loop
iam the thread loop
 
Es kommt also darauf an, ob die C Library vor oder nach pthreads kommt. Siehe auch die Reihenfolge der Ausgabe von ldd in #2 und #6.
 
..., ob die C Library vor oder nach pthreads kommt.
Ja. So:
Code:
./freetz_cc -lpthread [COLOR=red][B]-lc[/B][/COLOR] -o helloworld8 helloworld.o
funktioniert es:
Code:
root@fritz:/var/media/ftp/uStor01/archiv# ldd ./helloworld8
        [COLOR=blue]libpthread.so.0 => /lib/libpthread.so.0 (0x2aabe000)[/COLOR]
        [COLOR=red]libc.so.0 => /lib/libc.so.0 (0x2aae1000)[/COLOR]
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ab5c000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)
und so:
Code:
root@fritz:/var/media/ftp/uStor01/archiv# ldd ./helloworld7
        [COLOR=red]libc.so.0 => /lib/libc.so.0 (0x2aabe000)[/COLOR]
        [COLOR=blue]libpthread.so.0 => /lib/libpthread.so.0 (0x2ab39000)[/COLOR]
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ab5c000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)
funktioniert es nicht.
 
Es ist das Linken der libc, das die unerwünschte Ausgabe verursacht

Oh, die andere Reihenfolge war mir schon aufgefallen, als ich mein ldd output gepostet hatte. Wusste aber nciht, dass das von Bedeutung ist.
redfiniert die libpthread Symbole aus der libc?
Was bedeuten die hex-Zahl in Klammern?
 

Statistik des Forums

Themen
244,808
Beiträge
2,218,758
Mitglieder
371,494
Neuestes Mitglied
msh7
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.