Loading ...
Sorry, an error occurred while loading the content.
 

Strange libc issues (Debian)

Expand Messages
  • David Given
    I m trying to port a program of mine to run on my NSLU2 running Debian Etch; the program is Spey, an email greylisting proxy. Spey uses coroutines a lot, and
    Message 1 of 1 , Jun 3 5:37 PM
      I'm trying to port a program of mine to run on my NSLU2 running Debian Etch;
      the program is Spey, an email greylisting proxy.

      Spey uses coroutines a lot, and this is where I'm having the difficulties.
      Firstly, Spey's native coroutines implementation use
      makecontext()/getcontext()/etc, which the ARM glibc lacks. I managed to get
      round this by adding support for libpcl, which is a portable coroutine library
      that abuses signal handlers (apparently in a standards compliant way) to
      achieve the stack-switching trick.

      There are two main issues I'm seeing:

      Firstly, if I try to use any code that references pthreads, then the
      application dies. This includes malloc(), if the application has pulled in
      libpthread. Note that it's not necessary to *use* threads --- the mere
      presence of the library causes things to go wrong. In this case, my
      application uses libsqlite; since Debian's version of this has been built with
      threading support, trying to use libsqlite causes libpthread to be implicitly
      pulled in. Boom.

      (This is disturbingly similar to Debian bug #339827, which I filed --- and
      they fixed --- back when I was having exactly the same issue on i386. This was
      caused by Linuxthreads not coping with coroutines using stacks not owned by
      Linuxthreads. More modern threading libraries, such as the one used on i386
      2.6 kernels, don't have this restriction. Does ARM Linux use Linuxthreads as
      well?)

      After compiling my own copy of Sqlite without threading support, the second
      problem has become apparent; it seems that if I throw a C++ exception from
      inside a coroutine --- i.e., on a user stack --- then instead of the exception
      being caught by the most-recent exception frame on the user stack, it's
      instead caught by the exception frame on the main application stack. In other
      words, throwing an exception inside a coroutine will completely bypass all the
      exception handlers inside the coroutine and instead jump right out to my main
      application!

      I have identical code that compiles on both i386 and ARM that behaves
      differently, manifesting this problem.

      I suspect that the correct thing to do now is to try and come up with a
      minimal example and file another Debian bug report. However, in the mean time,
      I'd very much like a workaround --- Spey forms a major part of my
      spam-filtering arsenal, and until it works I can't use it.

      Can anyone with better ARM-fu than me suggest (a) why this is happening, and
      (b) what I can do to stop it?

      --
      +- David Given --McQ-+ "Gaping from its single obling socket was
      | dg@... | scintillating, many fauceted scarlet emerald..."
      | (dg@...) | --- Jim Theis, _The Eye of Argon_ (spelling
      +- www.cowlark.com --+ original)
    Your message has been successfully submitted and would be delivered to recipients shortly.