Recent changes to bugs

using va_list in the st_thread under FreeBSD 10.1 should cause signal SIGBUS Error

Bob Jiang — Tue, 16 Dec 2014 09:54:28 -0000

I meet an strange issue under the FreeBSD 10.1 (only on X64 include Amd64 and intel x64), when I use any var-arguments relation function in a state-thread, simple like the printf("Hello State-Threads.\n"), It'll cause signal SIGBUS Error.

This issue should only occur on my two computre with FreeBSD 10.1 (X64 and Amd64), and never meet it on Mac OSX 10.10.1 (X64), CentOS 7.0 (X64), FreeBSD 10.1 (i386).

my test case is attached after, please help!

#16 arm-linux MD_GET_SP offset is invalid.

Mike Abbott — Fri, 21 Mar 2014 12:12:13 -0000

Please provide a preprocessor directive for detecting when the index should be 20 vs. when it should be 8, so fixing it for your platform won't break legacy systems.

#15 fork process after st_init will got "wrong" state fd to read

Mike Abbott — Fri, 21 Mar 2014 12:08:37 -0000

Sounds like this could be either a misunderstanding about how to use ST, or an OS bug. Does the problem occur only when accepting a new connection on a socket? Perhaps you need to use st_netfd_serialize_accept() and/or update that function's implementation for your platform. If it happens with other functions please provide a small, simplified test program to reproduce the issue, along with the results it produces on your system and the results you expect it to produce.

arm-linux MD_GET_SP offset is invalid.

winterserver — Sun, 16 Mar 2014 13:19:13 -0000

in the md.h, line 425:
#define MD_GET_SP(_t) (_t)->context[0].__jmpbuf[20]
it will corrupt on debian armhf, for the sp offset is not 20, bug 8.

// /usr/arm-linux-gnueabi/include/bits/setjmp.h

ifndef _ASM

/ The exact set of registers saved may depend on the particular core
in use, as some coprocessor registers may need to be saved. The C
Library ABI requires that the buffer be 8-byte aligned, and
recommends that the buffer contain 64 words. The first 28 words
are occupied by v1-v6, sl, fp, sp, pc, d8-d15, and fpscr. (Note
that d8-15 require 17 words, due to the use of fstmx.)
/
typedef int jmp_buf[64] attribute((aligned__ (8)));

endif

0-5: v1-v6
6: sl
7: fp
8: sp
9: pc
10-26: d8-d15 17words
27: fpscr

when I change to:
#define MD_GET_SP(_t) (_t)->context[0].__jmpbuf[8]
it works!

fork process after st_init will got "wrong" state fd to read

winterserver — Sun, 16 Mar 2014 13:16:58 -0000

the st has a bug when:
1. master process start.
2. st_init, initialize st.
3. st_netfd_open, or other fd operations.
4. fork work processes
5. sometimes got a bug: st_poll detect a fd has data to read, but actually no data and read will be blocked. it seems the fd state is "wrong" whatever.

workaround: fork processes then use st.

Stacks not aligned on non-Linux i386

Matthew Ryan — Mon, 26 Mar 2012 01:53:01 -0000

I came across an issue where st would segfault when built with gcc 4.5.0 using -O3
on Solaris 10 i386. The issue turned out to be that the stack was not properly
aligned for the use of MMX/SSE instructions, which require their arguments to be
16-byte aligned.

The problem does not occur under linux because of the custom assembly used
in saving and restoring the context, which has an .align 16.

At least for GCC, the attached patch addresses the problem; it enables the fix
on the earliest version of GCC it is possible on (4.2.0).

Some more details:

On i386, GCC will ensure the stack is 16-byte aligned if necessary, but will only
check and re-align in main(), instead of in each function that uses those instructions.
The stacks created for st threads are not, then, covered by this, and will only be
word-aligned, which is the default for the i386 ABI.

GCC provides a force_align_arg_pointer function attribute, which will cause the
decorated function to ensure that the stack is aligned to the largest degree necessary.
Decorating st_thread_main() suffices to address the problem, as GCC will automatically
maintain alignment from there on in.

This is not required on x86-64, because that ABI explicitly requires that any array of
at least 16 bytes, or any C99 variable length array, be 16-byte aligned, specifically for
SSE instructions. Indeed, the force_align_arg_pointer attribute is not available for
that architecture.

References:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842
http://mail.python.org/pipermail/python-dev/2010-May/100050.html
http://www.sco.com/developers/devspecs/abi386-4.pdf
http://www.x86-64.org/documentation/abi.pdf

Doc: st_*msg() un-necessarily constrained to UDP

MarkD — Sun, 18 Dec 2011 03:13:37 -0000

Both st_sendmsg() and st_recvmsg() caution that "A file descriptor object identifier (see st_netfd_t) representing a UDP socket", but I don't think that constraint is valid. I've long used by st_sendmsg() and st_recvmsg() on a TCP socket to do, inter alia, fd-passing and the st library does just fine.

My suspicion is that this reference to UDP is just an artifact of a copy/paste of st_sendto() and st_recvfrom().

In any event, I think that restriction on UDP sockets should be removed from the docs or clarified as to when it does not work for TCP.

_st_iterate_threads() may cause thread to be re-entered

Xiaolin (Charlene) Zang — Wed, 27 May 2009 02:03:16 -0000

There is a bug in _st_iterate_threads(). The bug can be demonstrated with
the following program:

#include <stdio.h>
#include "public.h"

extern _st_iterate_threads_flag;

int a, *ap = &a;

static void * thread_fn(void *arg) {
printf("enter thread_fn\n");
*ap = 1000;
ap = NULL; // re-entry of this thread will cause a core dump
_st_iterate_threads();
printf("exit thread_fn\n");
return NULL;
}

int main(int argc, char *argv[])
{
st_init();
_st_iterate_threads_flag = 1;
st_thread_t t = st_thread_create(thread_fn, NULL, 1, 0);
st_thread_join(t, NULL);
}

With release 1.8, the program produces the following outcome:

my_machine > gcc try.c LINUX_2.6.24.5-smp_DBG/libst.a
my_machine > ./a.out
enter thread_fn
enter thread_fn
Segmentation fault (core dumped)

The bug in _st_iterate_threads() causes thread_fn to be re-entered. The
following diff fixes the problem. With this diff, the output of the above
test program is

my_machine > ./a.out
enter thread_fn
show thread msg: Iteration started
show thread msg: Iteration: a new thread
show thread msg: Iteration: a running thread
show thread msg: Iteration completed
exit thread_fn

The diff is explained with the comments in _st_iterate_threads(). I added
some non-essential messages to show the control flow in the test program.

--- common.h.save 2009-05-26 14:46:21.000000000 -0400
+++ common.h 2009-05-26 14:47:05.000000000 -0400
@@ -310,6 +310,7 @@
#define _ST_FL_ON_SLEEPQ 0x04
#define _ST_FL_INTERRUPT 0x08
#define _ST_FL_TIMEDOUT 0x10
+#define _ST_FL_STARTING 0x20

--- sched.c.save 2009-05-26 14:46:00.000000000 -0400
+++ sched.c 2009-05-26 14:57:29.000000000 -0400
@@ -168,7 +168,7 @@
NULL, 0, 0);
if (!_st_this_vp.idle_thread)
return -1;
- _st_this_vp.idle_thread->flags = _ST_FL_IDLE_THREAD;
+ _st_this_vp.idle_thread->flags |= _ST_FL_IDLE_THREAD;
_st_active_count--;
_ST_DEL_RUNQ(_st_this_vp.idle_thread);

@@ -316,6 +316,9 @@
{
_st_thread_t *thread = _ST_CURRENT_THREAD();

+ assert(thread->flags & _ST_FL_STARTING);
+ thread->flags &= ~_ST_FL_STARTING;
+
/*
* Cap the stack by zeroing out the saved return address register
* value. This allows some debugging/profiling tools to know when
@@ -587,6 +590,13 @@
thread->start = start;
thread->arg = arg;

+ /*
+ * _ST_FL_STARTING indicates that the thread has been created but has
+ * not started its execution yet. See _st_iterate_threads_helper() for more
+ * info.
+ */
+ thread->flags |= _ST_FL_STARTING;
+
#ifndef __ia64__
_ST_INIT_CONTEXT(thread, stack->sp, _st_thread_main);
#else
@@ -624,7 +634,7 @@
/* ARGSUSED */
void _st_show_thread_stack(_st_thread_t *thread, const char *messg)
{
-
+ printf("show thread msg: %s\n", messg);
}

/* To be set from debugger */
@@ -646,7 +656,7 @@

if (thread) {
memcpy(thread->context, save_jb, sizeof(jmp_buf));
- _st_show_thread_stack(thread, NULL);
+ _st_show_thread_stack(thread, "Iteration: a running thread");
} else {
if (MD_SETJMP(orig_jb)) {
_st_iterate_threads_flag = 0;
@@ -658,13 +668,28 @@
_st_show_thread_stack(thread, "Iteration started");
}

- q = thread->tlink.next;
- if (q == &_ST_THREADQ)
- q = q->next;
- ST_ASSERT(q != &_ST_THREADQ);
- thread = _ST_THREAD_THREADQ_PTR(q);
- if (thread == _ST_CURRENT_THREAD())
- MD_LONGJMP(orig_jb, 1);
+ while (1) {
+ q = thread->tlink.next;
+ if (q == &_ST_THREADQ) // _ST_THREADQ is part of _st_this_vp, skip
+ q = q->next;
+ ST_ASSERT(q != &_ST_THREADQ);
+ thread = _ST_THREAD_THREADQ_PTR(q);
+ if (thread == _ST_CURRENT_THREAD()) {
+ MD_LONGJMP(orig_jb, 1); // Looped back to current thread. Done.
+ }
+ /*
+ * When a thread is created but haven't started running yet (haven't
+ * got to _st_thread_main), simply longjmp to that thread's context (set
+ * by MD_INIT_CONTEXT) causes _ST_CURRENT_THREAD's start function to be
+ * re-executed. Flag _ST_FL_STARTING is to indicate a thread is in
+ * such state and we'll avoid longjmp.
+ */
+ if (thread->flags & _ST_FL_STARTING) {
+ _st_show_thread_stack(thread, "Iteration: a new thread");
+ } else {
+ break;
+ }
+ }
memcpy(save_jb, thread->context, sizeof(jmp_buf));
MD_LONGJMP(thread->context, 1);
}

st-1.8 does not compile on Darwin/Intel

Anonymous — Thu, 15 Jan 2009 18:52:12 -0000

Make fails as follows:

$ make darwin-optimized
make OS="DARWIN" BUILD="OPT"
cc -DDARWIN -Wall -O -c sched.c -o DARWIN_9.6.0_OPT/sched.o
In file included from common.h:62,
from sched.c:48:
md.h:129:2: error: #error Unknown CPU architecture

On examination of md.h it appears that only PPC has a defined MD_JB_SP. I'm sorry that I don't know what that value shoud be for Intel, nor how to work out what it should be so I can offer no assistance on that front.

Check return codes everywhere

Markus Elfring — Fri, 23 Mar 2007 21:14:22 -0000

Some checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from "close" and "fcntl" in the function "_st_epoll_dispatch"?
http://downloads.sourceforge.net/state-threads/st-1.8.tar.gz