Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2007-04

problem with threads and backgrounding, fpc 2.1.3 arm native

13 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Luca Olivetti

[I'm not sure if this should go here or fpc-devel]

Hello,
I'm quite impressed by the native arm compiler that I grabbed here ftp://ftp.freepascal.org/pub/fpc/beta/2.1.2/arm-linux/. My small but relatively complex program (with various threads using synchronize and critical sections, c library with callbacks to pascal, etc.) is working flawlessly in the foreground, but it segfaults if I try to background it (or try to use fpFork), and this is a problem since I want to write a daemon (i can use screen though if that isn't possible).

This small program exhibits the same problem:

---8<-------8<-------8<-------8<----------
program test;
{$mode objfpc}{$H+}
uses cthreads,sysutils,classes;
type
   tmt=class(TThread)
     procedure execute;override;
   end;
var
   mt:tmt;
procedure tmt.execute;
begin
   while not terminated do sleep(100);
end;
begin
   mt:=tmt.create(false);
   sleep(5000);
   write('press enter to finish');
   readln;
   mt.free;
end.
---8<-------8<-------8<-------8<----------

If you try to bacground it with ctrl+z during the sleep(5000) it will segfaults:

./test

[1]+ Stopped ./test
fg
./test
An unhandled exception occurred at $BEE2C9C8 :
EAccessViolation : Access violation
$BEE2C9C8
$000103B0

If you remove the thread or try to background it after the sleep there's no problem. Also the same program under i386 (but compiled with fpc 2.0.4) has no such problem.
I'm running it on a linkstation pro with freelink (debian etch):

cat /proc/cpuinfo
Processor : ARM926EJ-Sid(wb) rev 0 (v5l)
BogoMIPS : 266.24
Features : swp half thumb fastmult edsp java CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 0
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 32768
I assoc : 1
I line length : 32
I sets : 1024
D size : 32768
D assoc : 1
D line length : 32
D sets : 1024

Hardware : MV-88fxx81
Revision : 0000
Serial : 0000000000000000

uname -a
Linux lspro 2.6.12.6-arm1 #77 Tue Dec 5 22:23:46 CST 2006 armv5tejl GNU/Linux

Bye

Luca A: Because it destroys the flow of the conversation Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists?
Micha Nelissen
to Luca Olivetti
Luca Olivetti wrote
synchronize and critical sections, c library with callbacks to pascal, etc.) is working flawlessly in the foreground, but it segfaults if I try to background it (or try to use fpFork), and this is a problem since I want to write a daemon (i can use screen though if that isn't possible).

Backgrounding is not the same as forking. Backgrounding is using the shell's job control (and sends some signal(s) to the process), forking is what the program does itself. Can you list an example that crashes with fpfork, and give an strace with it ?

Micha

Luca Olivetti
to Micha Nelissen: Backgrounding is not the same as forking. Backgrounding is using the shell's job control…

En/na Micha Nelissen ha escrit:

Show quoted text 7 lines
Luca Olivetti wrote: > synchronize and critical sections, c library with callbacks to pascal, > etc.) is working flawlessly in the foreground, but it segfaults if I try > to background it (or try to use fpFork), and this is a problem since I > want to write a daemon (i can use screen though if that isn't possible). Backgrounding is not the same as forking.

I (vaguely) understand the difference, but I think (probably mistakenly) that the problems are related.

Backgrounding is using the shell's job control (and sends some signal(s) to the process), forking is what the program does itself. Can you list an example that crashes with fpfork, and give an strace with it ?

the example daemon.pp, for example, crashes right away, strace doesn't seem very useful to me:

strace -f ./daemon
execve("./daemon", ["./daemon"], [/* 22 vars */]) = 0 syscall: unknown syscall trap 0x00008000

A simple program that just repeatedly sleeps after the fork, dies as soon as it receives any signal (e.h HUP, USR1).

Bye

Luca
Luca Olivetti
to Micha Nelissen: I've gotten access to an arm-linux system, where I cannot reproduce the crash. That…

En/na Micha Nelissen ha escrit:

Show quoted text 8 lines
Luca Olivetti wrote: > uname -a > Linux lspro 2.6.12.6-arm1 #77 Tue Dec 5 22:23:46 CST 2006 armv5tejl > GNU/Linux I've gotten access to an arm-linux system, where I cannot reproduce the crash. That system is using 2.6.18 kernel. Can you try a newer kernel as well ?

Unfortunately no. The fine are working hard
trying to make a newer kernel work on this machine, but it will take a while. I'll have to wait :-(

Bye

Luca
Micha Nelissen
to Luca Olivetti: En/na Micha Nelissen ha escrit: I (vaguely) understand the difference, but I think…
Luca Olivetti wrote
> Backgrounding is not the same as forking. I (vaguely) understand the difference, but I think (probably mistakenly) that the problems are related.

I'm not saying the problems are not related; they may be. It's just important to know there is a difference.

Show quoted text 6 lines
the example daemon.pp, for example, crashes right away, strace doesn't seem very useful to me: strace -f ./daemon execve("./daemon", ["./daemon"], [/* 22 vars */]) = 0 syscall: unknown syscall trap 0x00008000

There is a patch on the internet for strace, to skip this error. Google for strace syscall trap.

A simple program that just repeatedly sleeps after the fork, dies as soon as it receives any signal (e.h HUP, USR1).

Ok, this will be the same problem as with backgrounding in the shell.

Micha

Luca Olivetti
to Luca Olivetti: En/na Micha Nelissen ha escrit: I (vaguely) understand the difference, but I think…

En/na Luca Olivetti ha escrit:

the example daemon.pp, for example, crashes right away, strace doesn't seem very useful to me:

but it works fine cross-compiling (with fpc 2.0.4). I cannot find a way to cross-compile my test program:

fork]$ ppcarm
-Fu/home/luca/fpc-arm-2.0.4/lib/fpc/2.0.4/units/arm-linux/* -XParm-linux- -Xd -Xr/home/luca/lsproroot/usr/lib/ test.pas Free Pascal Compiler version 2.0.4 [2006/08/23] for arm Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Linux for ARM
Compiling test.pas
Assembling test
Linking test
/home/luca/fpc-arm-2.0.4/bin/arm-linux-ld: cannot find -ldl test.pas(12,3) Error: Error while linking

Bye

Luca
Luca Olivetti
to Luca Olivetti

En/na Luca Olivetti ha escrit:

Show quoted text 11 lines
En/na Luca Olivetti ha escrit: > the example daemon.pp, for example, crashes right away, strace doesn't > seem very useful to me: but it works fine cross-compiling (with fpc 2.0.4). I cannot find a way to cross-compile my test program: fork]$ ppcarm -Fu/home/luca/fpc-arm-2.0.4/lib/fpc/2.0.4/units/arm-linux/* -XParm-linux- -Xd -Xr/home/luca/lsproroot/usr/lib/ test.pas

After reading the fine documentation I think I found the correct incantation of the command (/home/luca/lsproroot has the lspro nfs mounted, so the libs are there) but still it doesn't work:

fork]$ ppcarm
-Fu/home/luca/fpc-arm-2.0.4/lib/fpc/2.0.4/units/arm-linux/* -Fl/home/luca/lsproroot/lib -Fl/home/luca/lsproroot/usr/lib -XParm-linux- -Xd -Xr/lib:/usr/lib test.pas
Free Pascal Compiler version 2.0.4 [2006/08/23] for arm Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Linux for ARM
Compiling test.pas
Assembling test
Linking test
/home/luca/fpc-arm-2.0.4/bin/arm-linux-ld: skipping incompatible /home/luca/lsproroot/usr/lib//libdl.so when searching for -ldl /home/luca/fpc-arm-2.0.4/lib/fpc/2.0.4/units/arm-linux/rtl/cthreads.o(.text+0x18): In function `CTHREADS_LOADPTHREADS$$BOOLEAN':
: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /home/luca/lsproroot/usr/lib//libdl.a(dlopen.o)(.text+0x1c): In function `dlopen':
: undefined reference to `__dlopen'
/home/luca/lsproroot/usr/lib//libdl.a(dlclose.o)(.text+0x0): In function `dlclose':
: undefined reference to `__dlclose'
/home/luca/lsproroot/usr/lib//libdl.a(dlsym.o)(.text+0x1c): In function `dlsym':
: undefined reference to `__dlsym'
test.pas(12,3) Error: Error while linking

Bye

Luca
Luca Olivetti
to Luca Olivetti

En/na Luca Olivetti ha escrit:

Show quoted text 16 lines
En/na Luca Olivetti ha escrit: > En/na Luca Olivetti ha escrit: > >> the example daemon.pp, for example, crashes right away, strace >> doesn't seem very useful to me: > > but it works fine cross-compiling (with fpc 2.0.4). > I cannot find a way to cross-compile my test program: > > fork]$ ppcarm > -Fu/home/luca/fpc-arm-2.0.4/lib/fpc/2.0.4/units/arm-linux/* > -XParm-linux- -Xd -Xr/home/luca/lsproroot/usr/lib/ test.pas After reading the fine documentation I think I found the correct incantation of the command (/home/luca/lsproroot has the lspro nfs mounted, so the libs are there) but still it doesn't work:

[...]

: undefined reference to `__dlsym' test.pas(12,3) Error: Error while linking

Ok, google told me that it was a probably a symbolic link, fixed it to be relative and I managed to cross-compile the test program No crash.
OTOH my real program, even if cross-compiled (what a pain!), is still throwing an exception if I use ctrl-z, is still having problems with fork but at least (if I leave it in the foreground) I can use ctrl+c.

Bye

Luca
Luca Olivetti
to Luca Olivetti

En/na Luca Olivetti ha escrit:

OTOH my real program, even if cross-compiled (what a pain!), is still throwing an exception if I use ctrl-z, is still having problems with fork but at least (if I leave it in the foreground) I can use ctrl+c.

This is another test program that shows my problem with fork: as soon as I start the thread, the main program stops working (the thread *is* running, you can put a writeln in its loop to show it). Note that in this short example I don't close stdin,stdout,stderr, I don't block signals but it doesn't matter (I did it all and the result is the same). The same happens with the native compiler and the cross compiler.

Now, if I remove the fork part, both the thread and the main loop work, but if I use crtl-z and then fg after the thread has started it will give an EAccessViolation, but this only with the native compiler (remind that the native compiler is 2.1.3 while the cross compiler is 2.0.4).

---------8<--------8<-------8<--------8<----------
program test2;
{$mode objfpc}{$H+}
uses cthreads,sysutils,classes,baseunix;
type
   tmt=class(TThread)
     procedure execute;override;
   end;
var
   mt:tmt;
   t:TPid;
   i:integer;
procedure tmt.execute;
begin
   while not terminated do sleep(1000);
end;
begin
   t:=FpFork;
   if t<0 then
   begin
     writeln('fork failed');
     halt(t);
   end;
   if t>0 then Halt(0); //parent
   while true do
   begin
     i:=i+1;
     writeln('running ',i);
     sleep(1000);
     if i=5 then mt:=tmt.create(false);
   end;
end.
---------8<--------8<-------8<--------8<----------

Bye

Luca
Micha Nelissen
to Luca Olivetti
Luca Olivetti wrote 6 lines
This is another test program that shows my problem with fork: as soon as I start the thread, the main program stops working (the thread *is* running, you can put a writeln in its loop to show it). Note that in this short example I don't close stdin,stdout,stderr, I don't block signals but it doesn't matter (I did it all and the result is the same). The same happens with the native compiler and the cross compiler.

I can reproduce this,

(gdb) bt
#0 0x401afd80 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0x401aea7c in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#2 0x401afc40 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0

Seems like it's waiting for some signal to be passed to the process, but it doesn't happen.

Micha

Luca Olivetti
to Luca Olivetti: En/na Luca Olivetti ha escrit: This is another test program that shows my problem with…

En/na Luca Olivetti ha escrit:

Show quoted text 11 lines
This is another test program that shows my problem with fork: as soon as I start the thread, the main program stops working (the thread *is* running, you can put a writeln in its loop to show it). Note that in this short example I don't close stdin,stdout,stderr, I don't block signals but it doesn't matter (I did it all and the result is the same). The same happens with the native compiler and the cross compiler. Now, if I remove the fork part, both the thread and the main loop work, but if I use crtl-z and then fg after the thread has started it will give an EAccessViolation, but this only with the native compiler (remind that the native compiler is 2.1.3 while the cross compiler is 2.0.4).

Now tested with a self-built 2.1.4 and it does the same. Unfortunately I still cannot test with a newer kernel.

[test program removed, original post available at: http://lists.freepascal.org/lists/fpc-pascal/2007-April/013558.html]

Bye

Luca
Luca Olivetti
to Luca Olivetti

En/na Luca Olivetti ha escrit:

Show quoted text 20 lines
En/na Luca Olivetti ha escrit: > This is another test program that shows my problem with fork: as soon > as I start the thread, the main program stops working (the thread *is* > running, you can put a writeln in its loop to show it). Note that in > this short example I don't close stdin,stdout,stderr, I don't block > signals but it doesn't matter (I did it all and the result is the same). > The same happens with the native compiler and the cross compiler. > > Now, if I remove the fork part, both the thread and the main loop > work, but if I use crtl-z and then fg after the thread has started it > will give an EAccessViolation, but this only with the native compiler > (remind that the native compiler is 2.1.3 while the cross compiler is > 2.0.4). Now tested with a self-built 2.1.4 and it does the same. Unfortunately I still cannot test with a newer kernel. [test program removed, original post available at: http://lists.freepascal.org/lists/fpc-pascal/2007-April/013558.html]

Just tried again with the 2.2.0 compiler available at ftp://ftp.freepascal.org/pub/fpc/dist/arm-linux-2.2.0/

Without the fork everything seems to work ok, ctrl-z and then fg (or bg) doesn't cause the EAccessViolation anymore.
With the fork the main loop stops as soon as the thread starts.

Bye

Luca