state-threads-devel Mailing List for State Threads Library

> After upgrading to macOS Mojave (Darwin 18.x?) my statethreads based programs crash.

Yeah, as of Mojave setjmp scrambles addresses it stores in the jmp_buf.  ST changes values in jmp_bufs in order to run different threads.  When longjmp descrambles those addresses, they become garbage.  Here's a related thread: <https://reviews.llvm.org/D51064>.

ST has its own implementation of setjmp/longjmp for some systems to work around similar issues.  See _st_md_cxt_save/_st_md_cxt_restore in md.h and md.S.  Maybe those could be used or adapted for Mojave?  There might be other issues though, such as, does modern macOS really still allow arbitrary allocated memory to be used as a stack?

We would welcome a patch that makes ST work on Mojave.

After upgrading to macOS Mojave (Darwin 18.x?) my statethreads based
programs crash. Unfortunately I don't have much debug information
available due to other problems, hence I would like to know if
someone is successfully using statethreads on macOS Mojave and if
so, which compiler/options are used.

OpenBSD 6.4 introduced a new flag for mmap(2):

    * Implemented MAP_STACK option for mmap(2). At pagefaults and
      syscalls the kernel will check that the stack pointer points
      to MAP_STACK memory, which mitigates against attacks using
      stack pivots.

so this needs to be set:

Index: stk.c
===================================================================
RCS file: /home/ca/cvs/mta/statethreads/stk.c,v
retrieving revision 1.3
retrieving revision 1.3.12.1
diff -u -r1.3 -r1.3.12.1
--- stk.c	7 Sep 2005 22:40:34 -0000	1.3
+++ stk.c	4 Dec 2018 11:45:44 -0000	1.3.12.1
@@ -138,13 +139,15 @@
 #elif defined (MD_USE_BSD_ANON_MMAP)
   mmap_flags |= MAP_ANON;
 #else
-#error Unknown OS
+#error Unknown OS: unspecified ANON_MMAP option
+#endif
+#if defined (MAP_STACK)
+  mmap_flags |= MAP_STACK;
 #endif
 
   vaddr = mmap(NULL, size, PROT_READ | PROT_WRITE, mmap_flags, zero_fd, 0);
   if (vaddr == (void *)MAP_FAILED)
     return NULL;
-
 #endif /* MALLOC_STACK */
 
   return (char *)vaddr;

Hello,

According to this list archives, about a year ago, there was a discussion
about stack alignment issues on *BSD/amd64.

I can confirm that the issue is real, I was bitten by the same problem on
FreeBSD 10.1.

My own fix is somewhat simpler, but essentially accomplishes the same thing,
namely making sure that the alignment is on *odd* 8-byte boundary.  Perhaps
the comment I included with my patch would clarify the matter enough to lead
to the acceptance of the patch, since FreeBSD's own makecontext(3) function
ensures the same conditions.

http://www.freebsd.org/cgi/man.cgi?query=makecontext&sektion=3&manpath=FreeBSD+10.1-RELEASE

The patch is against release 1.9.

--- md.h	2009-10-01 20:46:43.000000000 +0200
+++ md.h	2014-12-16 22:52:34.000000000 +0100
@@ -161,6 +161,19 @@
 #define MD_JB_SP  34
 #elif defined(__amd64__)
 #define MD_JB_SP   2
+/*
+ * The following comment is taken from src/lib/libc/amd64/gen/makecontext.c
+ * It explains why we specifically break the alignment to 64 byte boundary
+ * that is unconditionally enforced by sched.c, by setting MD_STACK_PAD_SIZE
+ * to this funky value.
+ * Without this, anything using va_start() & friends fails unpredictably.
+ */
+        /*
+         * Account for arguments on stack and do the funky C entry alignment.
+         * This means that we need an 8-byte-odd alignment since the ABI expects
+         * the return address to be pushed, thus breaking the 16 byte alignment.
+         */
+#define MD_STACK_PAD_SIZE 8
 #else
 #error Unknown CPU architecture
 #endif

Cheers,
\Anton.
-- 
Our society can survive even a large amount of irrational regulation.
  -- John McCarthy

After more digging I found another difference between Linux and
*BSD: the former uses md.S. So after using that also on *BSD, the
test program (and my application) does not crash anymore.

A patch is attached as well as the complete md.h with more changes.
Note: these are not well tested but based on feedback I got.
Hopefully someone can verify or at least test them.

A small test program is attached.
It crashes with OpenSSL 1.0.1e on
OpenBSD 5.4 amd64
FreeBSD 8.4 amd64 gcc 4.2.1 20070831
It does not crash on Linux amd64 (CentOS 5.3? gcc 4.1.2)):

%rsp is different on Linux vs *BSD. I don't know why...

--------------------
FreeBSD:
$ gdb stack1
GNU gdb 6.1.1 [FreeBSD]
(gdb) b sha1_block_data_order_ssse3
Breakpoint 1 at 0x414cf0: file sha1-x86_64.s, line 1295.
(gdb) run a
Starting program: obj/statethreads/examples/stack1 a

Breakpoint 1, sha1_block_data_order_ssse3 () at sha1-x86_64.s:1295
1295            pushq   %rbx
Current language:  auto; currently asm
(gdb) p $rsp
$1 = (void *) 0x80064abe0

(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
sha1_block_data_order_ssse3 () at sha1-x86_64.s:1328
1328            movdqa  %xmm0,0(%rsp)
(gdb) where
#0  sha1_block_data_order_ssse3 () at sha1-x86_64.s:1328

--------------------
Linux:
$ gdb ./stack1
GNU gdb Fedora (6.8-27.el5)
...
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) b sha1_block_data_order_ssse3
Breakpoint 1 at 0x412ad0
(gdb) run a
Starting program: obj.Linux.2.6.18.64/statethreads/examples/stack1 a

Breakpoint 1, 0x0000000000412ad0 in sha1_block_data_order_ssse3 ()
(gdb) p $rsp
$1 = (void *) 0x2b961b87ac68
(gdb) cont
Continuing.
arg=a

On Wed, Dec 18, 2013, Michael Abbott wrote:

> Your patch changes the stack base from being 64-byte aligned to
> being only 8-byte aligned which seems backwards and could break
> other code.  I'm afraid I won't adopt your patch into the ST

I have to admit I'm confused by the alignment issue too, but the
ABI for AMD64 states:

=== http://x86-64.org/documentation/abi.pdf (page 17) ===
3.2.2     The Stack Frame
...
    The end of the input argument area shall be aligned on a 16 (32, if __m256
is passed on stack) byte boundary. In other words, the value (%rsp + 8) is
always a multiple of 16 (32) when control is transferred to the function entry
point. The stack pointer, %rsp, always points to the end of the latest allocated
stack frame.
=== cut ===

So this means rsp % 16 == 8 on function entry, but this is not the case
in the debug output (it's rsp % 16 == 0 which looked fine to me until
someone pointed me to the ABI).

Do you have a program for statethreads that uses OpenSSL 1.0.1e
on amd64 with asm code for SHA1?
Maybe I can try to write a small test program (currently it's the
MeTA1 smtp server that triggers the problem) if you would be
interested in looking into this.


PS: the patch that I attached is wrong for FreeBSD as it changes
the stack layout for i386 too (and it is against my MeTA1 version,
not the original 1.9). That was not intended.

Thanks for the report.  Googling for "movdqa alignment" turns up some interesting links such as this very informative one:  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838.  I see in your example that the stack is 32-byte aligned before the pushq but then is no longer aligned properly for the movdqa.  This seems more like a compiler issue than a state threads issue, since state threads ensures that the stack starts 64-byte aligned.  Have you tried compiler options like -mstackrealign or whatever your compiler supports?

Your patch changes the stack base from being 64-byte aligned to being only 8-byte aligned which seems backwards and could break other code.  I'm afraid I won't adopt your patch into the ST distribution as is -- but of course you are welcome to run with your patched version all you like.  If you can devise a more general, universally safe patch I will reconsider.

It seems the stack alignment on AMD64 (BSD) is broken.  My program
crashes when linked with OpenSSL 1.0.1e due to a misaligned stack
(see below).
According to the AMD64 ABI %rsp must be congruent 8 modulo 16
on function entry.

I'm attaching a hack to deal with this, but it needs to be reviewed
and maybe fixed? It fixes my test program, but that's of course not
sufficient as "proof" that this is correct.

Breakpoint 5, sha1_block_data_order_ssse3 () at sha1-x86_64.s:1295
1295    pushq   %rbx
Current language:  auto; currently asm
(gdb) p $rsp
$15 = (void *) 0x8007360a0

This is wrong and causes a crash here:

1328    movdqa  %xmm0,0(%rsp)
(gdb) n

Program received signal SIGBUS, Bus error.
sha1_block_data_order_ssse3 () at sha1-x86_64.s:1328

(gdb) where
#0  sha1_block_data_order_ssse3 () at sha1-x86_64.s:1295
#1  0x000000000045bc68 in SHA1_Final (md=0x8007361d8 "Øu÷¸;¤¿Pqs\224­½0sÜ¢·ñþ", c=0x800c39240) at md32_common.h:372
#2  0x0000000000487bb4 in final (ctx=0x8007361a8, md=0x8007361d8 "Øu÷¸;¤¿Pqs\224­½0sÜ¢·ñþ") at m_sha1.c:81
#3  0x00000000004800ec in EVP_DigestFinal_ex (ctx=0x8007361a8, md=0x8007361d8 "Øu÷¸;¤¿Pqs\224­½0sÜ¢·ñþ", size=0x0)
    at digest.c:272
#4  0x000000000050e089 in ssleay_rand_add (buf=0x8007362a0, num=8, add=0) at md_rand.c:289
#5  0x000000000047da97 in RAND_add (buf=0x8007362a0, num=8, entropy=0) at rand_lib.c:157
#6  0x000000000040de2b in ssl23_accept (s=0x800c49c00) at s23_srvr.c:155
#7  0x000000000041a384 in SSL_accept (s=0x800c49c00) at ssl_lib.c:940
#8  0x000000000040b2dd in do_tls_operation (fp=<value optimized out>, hsfunc=0x41a350 <SSL_accept>, rfunc=0, wfunc=0, 
    buf=0x0, num=0, bytes=0x8007384a8) at ../../mta/libmta/tlsbio.c:218
#9  0x0000000000405394 in handle_session (srv_socket_index=<value optimized out>, cli_nfd=0x800c06ac0)
    at ../../../mta/statethreads/examples/smtps2.c:2904
#10 0x0000000000408c43 in handle_connections (arg=0x0) at ../../../mta/statethreads/examples/smtps2.c:1778
#11 0x000000000056e38f in _st_thread_main () at ../../mta/statethreads/sched.c:329
#12 0x000000000056e473 in st_thread_create (start=0x4089e0 <handle_connections>, arg=0x0, joinable=0, 
    stk_size=<value optimized out>) at ../../mta/statethreads/sched.c:593
#13 0x0000000000000000 in ?? ()

>	for (qp = _st_free_stacks.next; qp != &_st_free_stacks; qp = qp->next)
> when is _st_free_stack.next!= qp?

_st_free_stacks is a circular linked list.  When the list is empty,
_st_free_stacks.next == _st_free_stacks.prev == &_st_free_stacks.  To
traverse the list the loop starts with _st_free_stacks.next and follows
the chain via qp->next until it reaches the end of the list, when
qp->next == &_st_free_stacks.

> How does [offsetof] work?

The offsetof macro returns the offset in bytes of a structure member
from the address of the struct.	 It achieves this by pretending it has
an object of the struct type at address 0, then asking the compiler what
the address is of the member of that struct.  This is perfectly safe and
legitimate because it never dereferences the 0 pointer, it just does
pointer math.

> #define _ST_THREAD_STACK_PTR(_qp)

The purpose of this macro is to find the address of (i.e., a pointer to
the) _st_stack_t object given the address of the object's "links"
member.	 When the CLIST macros put an object on a linked list, they do
so using a member of the structure.  To get the structure itself it is
necessary to subtract the offset of that member.  For structures such as
_st_stack the links member is the first member so the address of the
structure is the same as the address of the structure's links member (sp
== &sp->links).	 But look at _st_thread:  it has multiple _st_clist_t
members because it can be on different lists.  It's linked into those
lists via its "links" or "wait_links" members not the structure itself.
So to determine a (_st_thread_t *) from the links member it subtracts
the offset of links.  tp == &tp->links - offsetof(_st_thread_t, links).

Hi Dear ST Developers and Users,

I am reading ST 1.9's source has encounter a piece of code that I can't
figure out for a week.

In stk.c,

in the body of the function

_st_stack_t *_st_stack_new(int stack_size)

I understand this function is to allocate memory space for the stack. And
update the stack records.

There is this piece

for (qp = _st_free_stacks.next; qp != &_st_free_stacks; qp = qp->next)
 //when is _st_free_stack.next!= qp?
{
ts = _ST_THREAD_STACK_PTR(qp);
/*
Here I lookup what _ST_THREAD_STACK_PTR does and found

#define offsetof(type, identifier) (/***/ (size_t)&(/**/( (type
*)0)->identifier/**/) /***/)
It looks like this macro finds a instance of "_st_stack_t"'s element "links"
's address and cast it into size_t type?
I am totally confused about this! Cast address 0 points to _st_stack_t type
variable, but the space is never allocated yet. How does this work?


#define _ST_THREAD_STACK_PTR(_qp)   \
    (/**/ (_st_stack_t *)(/***/ (char*)(_qp) - offsetof(_st_stack_t, links)
/***/) /**/)
cast _st_clist_t type variable _qp to into byte point and minus this
"offset" that I don't understand. Confused again.

_qp is of _st_clist_t type,

*/
if (ts->stk_size >= stack_size)
{
/* Found a stack that is big enough */
ST_REMOVE_LINK(&ts->links);
_st_num_free_stacks--;
ts->links.next = NULL;
ts->links.prev = NULL;
return ts;
}
}

What does this for loop do?
I notice at the beginning of stk.c,
_st_clist_t _st_free_stacks = ST_INIT_STATIC_CLIST(&_st_free_stacks);
This set _st_free stack 's next and prev pointer pointing to itself.
Inside _st_stack_new(...), I don't see _st_free_stacks is changed.

I guess _st_list_t type is a link list. However, it has only next and prev
pointers. Where is the data?

Thanks a lot for any suggestions!
Alfred

Oh my god!

+ _ST_PAGE_SIZE - 1

if stk_size is just x times of the _ST_PAGE_SIZE, the integer division will
return exactly x b/c of the -1.

if stk_size is smaller than x times of _ST_PAGE_SIZE, the integer division
will return exactly x, and ignore the remaining >x but <x+1

That is smart!
If the purpose is in the comment or docs will be better to understand

Thanks a lot, John!

Alfred

On Wed, Aug 10, 2011 at 1:11 PM, John Newton <jn...@gm...> wrote:

> The line you are asking about is a "round up" to the next page size
> calculation.
>
> For example, if getpagesize() returns 4096, and the "stk_size" parameter is
> 10,000 it would round up to the next even page size. (the division is doing
> integer math)
>
> Hope this helps!
>
> On Wed, Aug 10, 2011 at 9:06 AM, Alfred Zhong <alf...@gm...>wrote:
>
>> Hi,
>> I am new to state thread library and am reading the source code of ST to
>> study implementation of threading.
>>
>> in the st_thread_create() function
>>
>> there is this code piece
>>
>> if (stk_size == 0)
>>     stk_size = ST_DEFAULT_STACK_SIZE;  // I know this is to set the stack
>> size to a default size, if the input size is 0
>>   stk_size = ((stk_size + _ST_PAGE_SIZE - 1) / _ST_PAGE_SIZE) *
>> _ST_PAGE_SIZE; //what does this mean?
>>
>> Look like it equals (stk_size + ST_PAGE_SIZE -1) unless the previous
>> division gives 0.
>>
>> I am totally confused and can't find the answer in the code or the docs,
>> please help!
>>
>> Thanks a lot!
>> Alfred
>>
>>
>> ------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>>
>> _______________________________________________
>> State-threads-users mailing list
>> Sta...@li...
>> https://lists.sourceforge.net/lists/listinfo/state-threads-users
>>
>>
>

The line you are asking about is a "round up" to the next page size
calculation.

For example, if getpagesize() returns 4096, and the "stk_size" parameter is
10,000 it would round up to the next even page size. (the division is doing
integer math)

Hope this helps!

On Wed, Aug 10, 2011 at 9:06 AM, Alfred Zhong <alf...@gm...> wrote:

> Hi,
> I am new to state thread library and am reading the source code of ST to
> study implementation of threading.
>
> in the st_thread_create() function
>
> there is this code piece
>
> if (stk_size == 0)
>     stk_size = ST_DEFAULT_STACK_SIZE;  // I know this is to set the stack
> size to a default size, if the input size is 0
>   stk_size = ((stk_size + _ST_PAGE_SIZE - 1) / _ST_PAGE_SIZE) *
> _ST_PAGE_SIZE; //what does this mean?
>
> Look like it equals (stk_size + ST_PAGE_SIZE -1) unless the previous
> division gives 0.
>
> I am totally confused and can't find the answer in the code or the docs,
> please help!
>
> Thanks a lot!
> Alfred
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>
> _______________________________________________
> State-threads-users mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/state-threads-users
>
>

Hi,
I am new to state thread library and am reading the source code of ST to
study implementation of threading.

in the st_thread_create() function

there is this code piece

if (stk_size == 0)
    stk_size = ST_DEFAULT_STACK_SIZE;  // I know this is to set the stack
size to a default size, if the input size is 0
  stk_size = ((stk_size + _ST_PAGE_SIZE - 1) / _ST_PAGE_SIZE) *
_ST_PAGE_SIZE; //what does this mean?

Look like it equals (stk_size + ST_PAGE_SIZE -1) unless the previous
division gives 0.

I am totally confused and can't find the answer in the code or the docs,
please help!

Thanks a lot!
Alfred

> I am interested in how to best support the Linux system call splice() within the ST framework

Welcome.

Start by studying the documentation for and implementations of st_read() and st_write().  Then write st_splice() based on what you learned.  You will have to use the SPLICE_F_NONBLOCK flag.  I wonder if an st_splice_fully() and an st_splice_resid() also make sense to implement?

Please let us know how it goes.

I am interested in how to best support the Linux system call splice() within
the ST framework, and if this has already been accomplished.

http://en.wikipedia.org/wiki/Splice_(system_call)

My specific application is a proxy where, after inspecting some of the data,
the program would want to have the next "n" bytes transfered directly from
the incoming socket to the outgoing.

Any pitfalls, comments or suggestions are welcome.

Regards,
John Newton

I recently updated the packaging for libst 1.9 in debian and happened
to notice that there are a number of private symbols leaked into the
shared library. Attached is a patch that I've applied in the debian
package to fix this issue. Please consider applying it upstream.

Thank you.

PS. I am not subscribed so please CC me on any replies.

This issue was resolved in just released version 1.7 of ST.

On Apr 14, 2006, at 2:06 PM, Jose Marcio Martins da Cruz wrote:

>
> Hi,
>
> Gene wrote:
>
>> Hmm, I have a sneaky suspicion that they finally made JB_SP a private
>> definition in new version of glibc (2.4). It's still defined  =20
>> internally in
>> sysdeps/i386/jmpbuf-offsets.h
>>
>
> Yes...
>
> I've got another answer from fedora devel list. (Ulrich Drepper =20
> from Red Hat Inc.).
>
> *********************************************************************
>
> Jose Marcio Martins da Cruz wrote:
>
> >> I tried to define myself the value of JB_SP (4 - the same value =20
> found in
> >> Fedora 4 headers), but the application segfaults.
>
>
> That value was never meant to be used by programs.  It was a value
> needed in the implementation and unfortunately it was placed in the
> public header.
>
> This is fixed now.  And for a good reason: you cannot access the =20
> values
> at all anymore today.  The stored values are "encrypted".
>
> You can disable the encryption using the LD_POINTER_GUARD environment
> variable.  Unfortunately the glibc version so far in FC5 has a little
> bug.  The next update will allow you to specify LD_POINTER_GUARD=3D0.
>
> But this is really the wrong solution.  The program should be =20
> rewritten
> to use __builtin_frame_address (see the gcc manual).
>
> -- =E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 =
Castro St =E2=9E=A7 =20
> Mountain View, CA =E2=9D=96
>
> *********************************************************************
>
>
> --=20
>   ---------------------------------------------------------------
>   Jose Marcio MARTINS DA CRUZ           Tel. :(33) 01.40.51.93.41
>   Ecole des Mines de Paris              http://j-chkmail.ensmp.fr
>   60, bd Saint Michel                http://www.ensmp.fr/~martins
>   75272 - PARIS CEDEX 06      mailto:Jos...@en...
>
>

Gene wrote:
> Hmm, I have a sneaky suspicion that they finally made JB_SP a private
> definition in new version of glibc (2.4). It's still defined  internally in
> sysdeps/i386/jmpbuf-offsets.h
> 
> Simple fix is to add this missing macro in md.h in the LINUX section:
> 
> #elif defined(__i386__)
> #define MD_STACK_GROWS_DOWN
> 
> #if defined(__GLIBC__) && __GLIBC__ >= 2
> #ifndef JB_SP
> /* From sysdeps/i386/jmpbuf-offsets.h in glibc 2.4 */
> #define JB_SP 4
> #endif
> #define MD_GET_SP(_t) (_t)->context[0].__jmpbuf[JB_SP]
> #else
> 
> Please give it a try.  If it works, we'll add this to the next ST  release.

I've already did it. It segfaults. 8-(

Moreover, Fedora 5 come with glibc 2.4.4 (not the official 2.4 release).

For a reason I don't know, the glibc installed with Fedora 5 doesn't
have this header file (jmpbuf-offsets.h). glibc 2.4 (glibc from gnu web
site has this header but not Fedora distributed glibc).

glibc versions are :

# rpm -qa|grep glibc
glibc-devel-2.4-4
glibc-kernheaders-3.0-5.2
glibc-2.4-4
glibc-common-2.4-4
glibc-headers-2.4-4

Odd thing 8-(


-- 
 ---------------------------------------------------------------
 Jose Marcio MARTINS DA CRUZ           Tel. :(33) 01.40.51.93.41
 Ecole des Mines de Paris              http://j-chkmail.ensmp.fr
 60, bd Saint Michel                http://www.ensmp.fr/~martins
 75272 - PARIS CEDEX 06      mailto:Jos...@en...

Hmm, I have a sneaky suspicion that they finally made JB_SP a private
definition in new version of glibc (2.4). It's still defined =20
internally in
sysdeps/i386/jmpbuf-offsets.h

Simple fix is to add this missing macro in md.h in the LINUX section:

#elif defined(__i386__)
#define MD_STACK_GROWS_DOWN

#if defined(__GLIBC__) && __GLIBC__ >=3D 2
#ifndef JB_SP
/* =46rom sysdeps/i386/jmpbuf-offsets.h in glibc 2.4 */
#define JB_SP 4
#endif
#define MD_GET_SP(_t) (_t)->context[0].__jmpbuf[JB_SP]
#else

Please give it a try.  If it works, we'll add this to the next ST =20
release.
Thanks!


On Mar 30, 2006, at 11:48 PM, Jose Marcio Martins da Cruz wrote:

>
> Hello,
>
> Someone (a sendmail X user) repported me problems compiling =20
> statethreads
> under Fedora 5.
>
> depmode=3Dgcc3 /bin/sh ./depcomp \
> cc -DHAVE_CONFIG_H -I. -I. -I. -I./../include -DLINUX -O -g -O2 -c =20
> `test
> -f 'sched.c' || echo './'`sched.c
> sched.c: In function =91st_thread_create=92:
> sched.c:892: erreur: =91JB_SP=92 undeclared (first use in this =
function)
> sched.c:892: erreur: (Each undeclared identifier is reported only once
> sched.c:892: erreur: for each function it appears in.)
> make[3]: *** [sched.o] Erreur 1
> make[3]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads'
> make[2]: *** [all-recursive] Erreur 1
> make[2]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads'
> make[1]: *** [all] Erreur 2
> make[1]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads'
> make: *** [all-recursive] Erreur 1
> [root@localhost smX-0.0.0.0]#
>
> It seems that Fedora 5 doesn't define JB_SP :
>
> # grep JB_SP /usr/include/*
> # grep JB_SP /usr/include/*/*
>
> glibc versions are :
>
> # rpm -qa|grep glibc
> glibc-devel-2.4-4
> glibc-kernheaders-3.0-5.2
> glibc-2.4-4
> glibc-common-2.4-4
> glibc-headers-2.4-4
>
> Hardware is Intel 32 bits.
>
> Regards,
>
> Jose-Marcio
>

Hello,

Someone (a sendmail X user) repported me problems compiling statethreads
under Fedora 5.

depmode=3Dgcc3 /bin/sh ./depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I. -I./../include -DLINUX -O -g -O2 -c `test
-f 'sched.c' || echo './'`sched.c
sched.c: In function =91st_thread_create=92:
sched.c:892: erreur: =91JB_SP=92 undeclared (first use in this function)
sched.c:892: erreur: (Each undeclared identifier is reported only once
sched.c:892: erreur: for each function it appears in.)
make[3]: *** [sched.o] Erreur 1
make[3]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads'
make[2]: *** [all-recursive] Erreur 1
make[2]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads'
make[1]: *** [all] Erreur 2
make[1]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads'
make: *** [all-recursive] Erreur 1
[root@localhost smX-0.0.0.0]#

It seems that Fedora 5 doesn't define JB_SP :

# grep JB_SP /usr/include/*
# grep JB_SP /usr/include/*/*

glibc versions are :

# rpm -qa|grep glibc
glibc-devel-2.4-4
glibc-kernheaders-3.0-5.2
glibc-2.4-4
glibc-common-2.4-4
glibc-headers-2.4-4

Hardware is Intel 32 bits.

Regards,

Jose-Marcio

--=20
 ---------------------------------------------------------------
 Jose Marcio MARTINS DA CRUZ           Tel. :(33) 01.40.51.93.41
 Ecole des Mines de Paris              http://j-chkmail.ensmp.fr
 60, bd Saint Michel                http://www.ensmp.fr/~martins
 75272 - PARIS CEDEX 06      mailto:Jos...@en...

* Mike Abbott <mj...@co...> [060307 09:04] wrote:
> > Is there any way to make fsync() asynchronous
> 
> My first guess would be No, because ST requires non-blocking I/O and
> descriptors to disk files can't be made non-blocking.  But I'll talk
> with Gene about it.  You mentioned async I/O but that's its own can of
> worms.  I've never relied on SIGIO; let me know how it works for you :).
> 
> If I were faced with this I would do the typical ST thing and spawn a
> persistent helper process.

You're right, you'd need a helper process to do this.

fsync(2) can not be made async.

-- 
- Alfred Perlstein
- CTO Okcupid.com / FreeBSD Hacker / All that jazz -

> Is there any way to make fsync() asynchronous

My first guess would be No, because ST requires non-blocking I/O and
descriptors to disk files can't be made non-blocking.  But I'll talk
with Gene about it.  You mentioned async I/O but that's its own can of
worms.  I've never relied on SIGIO; let me know how it works for you :).

If I were faced with this I would do the typical ST thing and spawn a
persistent helper process.

Is there any way to make fsync() asynchronous in the context of
statethreads? Currently a process that uses fsync() will block until
fsync() returns thus preventing any other operations from occuring.
Some OSs provide aio_fsync() but so far I have seen only aio_return()
to check for the status of an asynchronous I/O operation, not some
mechanism to get notified when the operation finished. SIGIO might
be another approach to the problem, but signals have their own
problems.

What I would like to see is some support in statethreads to make
fsync() a scheduling point, just like read()/write() for network
I/O. Any pointers/suggestions to accomplish this are welcome!

PS: I know I can use multiple processes to mitigate the problem,
but I am curious whether that limitation of statethreads can be
solved within the library itself (even if it's not portable but
only available for some OSs).

On Sat, Nov 19, 2005, David Syzdek wrote:

> Is there any active efforts to enable the use of autoconf, automake, and
> libtool when compiling state threads? If there are no active efforts, would

I use statethreads for my MTA and used auto* to integrate it with
the rest of the build system. I don't use libtool however.  You can
take a look at what I did by downloading sendmail X:

ftp://ftp.sendmail.org/pub/sendmail/smX-0.0.0.0.tar.gz