[erlang-questions] Using sigwait in linked driver causes erl_ddll:load to return {error, {open_error, -10}}

Hynek Vychodil <>
Sat Apr 18 09:38:15 CEST 2009


Signal handling is at per process handling in Linux (in *nix systems
generally). IMHO it is wrong idea using it in linked-in drivers at all. You
will end up with unmaintainable mess because each change in signal handling
in erts or any other linked-in driver will break whole system.

>From man page:

       sigwait  suspends  the  calling  thread until one of the signals in
set is delivered to the calling thread. It then stores the number of the
       signal received in the location pointed to by sig and returns. The
signals in set must be blocked and not ignored on entrance to sigwait. If
       the delivered signal has a signal handler function attached, that
function is not called.

As you can see, you can easily break things there. For example may be you
wait for same signal which is vital for erl_ddll:load or any other part of
erts.

On Sat, Apr 18, 2009 at 2:00 AM, Rob Elsner <> wrote:

> Greetings,
>
> I've been tinkering with the Linux timer API (following the examples
> given by the rt-tests programs) and a simple linked driver with
> Erlang.  This is my first foray into each of these, so forgive me if
> I'm over looking something simple.
>
> I'm using Gentoo Linux localhost 2.6.27-gentoo-r8 #4 SMP PREEMPT Fri
> Apr 17 08:19:37 MDT 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core
> Processor 5000+ AuthenticAMD GNU/Linux
>
> as well as erl Erlang (BEAM) emulator version 5.6.5 [source] [64-bit]
> [smp:2] [async-threads:0] [hipe] (I've tested with and without hipe)
>
> What I've found is that if I comment out my use of sigwait (which is
> in the process handler), erl_ddll:load will return ok.  If I leave
> this in, erl_ddll:load returns -10 status.
>
> Has anyone seen something like this?  Does anyone have more useful
> ideas how I can figure out why it's failing?  I was assuming a library
> mismatch but I can't figure out what, and I even leave in other sig*
> functions (such as sigemptyset and sigprocmask).
>
> I build with -fPIC -lrt -m64 -shared
>
> Thanks in advance,
> Rob Elsner
>
> Here's a quick strace of the output:
>
> 11683 getcwd("/home/me/workspace/timer/timer_test/ebin"..., 8191) = 38
> 11683 open("./timer_drv.so", O_RDONLY)  = 7
> 11683 read(7,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\n\0\0\0\0\0\0@"...,
> 832) = 832
> 11683 fstat(7, {st_mode=S_IFREG|0755, st_size=12728, ...}) = 0
> 11683 getcwd("/home/me/workspace/timer/timer_test/ebin"..., 128) = 38
> 11683 mmap(NULL, 2105776, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_DENYWRITE, 7, 0) = 0x7fa7b62b8000
> 11683 mprotect(0x7fa7b62ba000, 2093056, PROT_NONE) = 0
> 11683 mmap(0x7fa7b64b9000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 7, 0x1000) = 0x7fa7b64b9000
> 11683 close(7)                          = 0
> 11683 munmap(0x7fa7b62b8000, 2105776)   = 0
> 11683 clock_gettime(CLOCK_MONOTONIC, {8538, 165029854}) = 0
> 11683 write(4, "!"..., 1)               = 1
> 11684 <... poll resumed> )              = 1 ([{fd=3,
> revents=POLLIN|POLLRDNORM}])
> 11684 read(3,  <unfinished ...>
> 11683 ioctl(0, TIOCGWINSZ <unfinished ...>
> 11684 <... read resumed> "!"..., 32)    = 1
> 11683 <... ioctl resumed> , {ws_row=48, ws_col=247, ws_xpixel=1486,
> ws_ypixel=628}) = 0
> 11684 read(3, 0x4350e6f0, 32)           = -1 EAGAIN (Resource
> temporarily unavailable)
> 11684 clock_gettime(CLOCK_MONOTONIC, {8538, 168957734}) = 0
> 11683 getcwd( <unfinished ...>
> 11684 clock_gettime(CLOCK_MONOTONIC, {8538, 170047654}) = 0
> 11683 <... getcwd resumed>
> "/home/me/workspace/timer/timer_test/ebin"..., 8191) = 38
> 11684 poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=0,
> events=POLLIN|POLLRDNORM}], 2, 3593783 <unfinished ...>
> 11683 stat("/home/me/workspace/timer/timer_test/ebin/./io_lib_pretty.beam",
> 0x42d0dd20) = -1 ENOENT (No such file or directory)
> 11683 open("/home/me/workspace/timer/timer_test/ebin/./io_lib_pretty.beam",
> O_RDONLY) = -1 ENOENT (No such file or directory)
> 11683 stat("/usr/lib64/erlang/lib/kernel-2.12.5/ebin/io_lib_pretty.beam",
> 0x42d0dd20) = -1 ENOENT (No such file or directory)
> 11683 open("/usr/lib64/erlang/lib/kernel-2.12.5/ebin/io_lib_pretty.beam",
> O_RDONLY) = -1 ENOENT (No such file or directory)
> 11683 stat("/usr/lib64/erlang/lib/stdlib-1.15.5/ebin/io_lib_pretty.beam",
> {st_mode=S_IFREG|0644, st_size=27804, ...}) = 0
> 11683 open("/usr/lib64/erlang/lib/stdlib-1.15.5/ebin/io_lib_pretty.beam",
> O_RDONLY) = 7
> 11683 read(7, "FOR1\0\0l\224BEAMAtom\0\0\3|\0\0\0^\rio_lib_p"..., 27804) =
> 27804
> 11683 close(7)                          = 0
> 11683 getcwd("/home/me/workspace/timer/timer_test/ebin"..., 8191) = 38
> 11683 write(4, "!"..., 1 <unfinished ...>
> 11684 <... poll resumed> )              = 1 ([{fd=3,
> revents=POLLIN|POLLRDNORM}])
> 11684 read(3, "!"..., 32)               = 1
> 11684 read(3, 0x4350e6f0, 32)           = -1 EAGAIN (Resource
> temporarily unavailable)
> 11684 clock_gettime(CLOCK_MONOTONIC, {8538, 194262414}) = 0
> 11684 futex(0x89bc40, FUTEX_WAIT, 2, NULL <unfinished ...>
> 11683 <... write resumed> )             = 1
> 11683 futex(0x89bc40, FUTEX_WAKE, 1 <unfinished ...>
> 11684 <... futex resumed> )             = 0
> 11684 futex(0x89bc40, FUTEX_WAKE, 1)    = 0
> 11684 clock_gettime(CLOCK_MONOTONIC, {8538, 197150974}) = 0
> 11684 clock_gettime(CLOCK_MONOTONIC, {8538, 197823334}) = 0
> 11684 poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=0,
> events=POLLIN|POLLRDNORM}], 2, 3593755 <unfinished ...>
> 11683 <... futex resumed> )             = 1
> 11683 write(0, "{error,{open_error,-10}}"..., 24) = 24
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill your
boss.  Be a data hero!
Try Good Data now for free: www.gooddata.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090418/2b8ec229/attachment.html>


More information about the erlang-questions mailing list