_beginthread() and stack calling convention

QNX Newsgroups (Archives) qdn.public.qnx4
1

_beginthread() calls using stack calling convention (-5s) cause a SEGV, but
calls using register calling convention (-5s) work fine. I’m using a
trivial test program that just calls _beginthread(), sleeps, and exits,
with the second thread just sleeping and exiting too.

QNX4.25, Watcom 10.6

Has anyone else run across this? Is there a patch/workaround?

Unfortunately I need to use the stack calling convention to link to some
existing libraries. I suppose I could rewrite to use a fork() and shared
memory, but I’d rather hear about a fix/workaround. :slight_smile:

Thanks,

  • Larry
2

“Larry Martin” <Larry@syatech-no-spam-here.com> wrote in message
news:Xns9207A8D2BF0A6Larrysyatechcom@209.226.137.7…

_beginthread() calls using stack calling convention (-5s) cause a SEGV,
but
calls using register calling convention (-5s) work fine. I’m using a
trivial test program that just calls _beginthread(), sleeps, and exits,
with the second thread just sleeping and exiting too.

QNX4.25, Watcom 10.6

Has anyone else run across this? Is there a patch/workaround?

Unfortunately I need to use the stack calling convention to link to some
existing libraries. I suppose I could rewrite to use a fork() and shared
memory, but I’d rather hear about a fix/workaround. > :slight_smile:

Thread under QNX4.25 can be pretty nasty (you have one example).
fork and shared memory, if possible, would definitely be safer.

Thanks,

  • Larry
3

Larry Martin wrote:

Given the trivial test
program described earlier: Compiling with -3r and linking agains clib3r
works fine. Compiling with -3s and linking against clib3s SEGVs.

Can you post the trivial test case ?I can try it here, to at least
confirm the problem (not much I can do about it, though).

Rennie

4

“Mario Charest” <goto@nothingness.com> wrote in
news:ab9tml$flm$1@inn.qnx.com:

Thread under QNX4.25 can be pretty nasty (you have one example).
fork and shared memory, if possible, would definitely be safer.

I’m familiar with QNX4.25 threading issues, and I’ve successfully used the
threading model in several working programs. My problem is with a bug in
the clib3s libraries _beginthread() implementation. Given the trivial test
program described earlier: Compiling with -3r and linking agains clib3r
works fine. Compiling with -3s and linking against clib3s SEGVs.

I already have a working QNX4/Watcom implementation for this particular
module that uses threading. My problem is that I now have to link with a
module built with stack calling convention (compiled with gcc), but I’m
finding that the Watcom _beginthread() implementation in the clib3s library
has a SEGV problem.

The problem isn’t with my threading implementation, it’s with the clib3s
library. Can anyone know of a patch/workaround? (The problem manifests as
a SEGV in __qsem_wait(), which is called by __CBeginThread().)

And yes, I’m familiar with Watcom/GCC link issues, and have successfully
used this gcc-built library in other (non-threaded) Watcom-compiled
programs. It’s only the clib3s _beginthread() implementation that’s
causing trouble.

Thanks,

  • Larry
5

Absolutely!

I have written many fork() & shared memory apps under QNX4 with no problems.

My biggest gripe with the “so called threads” under QNX4 is that the most
common reason for having a multi-threaded app is to do multiple IO’s
concurrently. QNX4 threads do not return an errno value that can be
trusted. I.E. errno is not thread safe. So I can’t do an IO operation and
then if it fails check errno to see why it failed. Bummer!

“Mario Charest” <goto@nothingness.com> wrote in message
news:ab9tml$flm$1@inn.qnx.com…

Thread under QNX4.25 can be pretty nasty (you have one example).
fork and shared memory, if possible, would definitely be safer.

6

“Larry Martin” <Larry@syatech-no-spam-here.com> wrote in message
news:Xns92088AF7F9674Larrysyatechcom@209.226.137.7…

Rennie Allen <> rallen@csical.com> > wrote in
news:> 3CD8D71A.5060306@csical.com> :

Larry Martin wrote:
Given the trivial test
program described earlier: Compiling with -3r and linking agains
clib3r works fine. Compiling with -3s and linking against clib3s
SEGVs.

Can you post the trivial test case ?I can try it here, to at least
confirm the problem (not much I can do about it, though).


Here it is. It works fine when compiled with “cc -3r” and SEGVs when
compiled with “cc -3s”. Watcom 10.6 patch B, QNX 4.25.

(And yes, I’ve tried passing in a pointer to an allocated stack–it makes
no difference.)

Thanks for the sanity check…

Don’t know if it’s related to your problem but last time I checked, sleep
wasn’t thread safe.

  • Larry

#include <stdio.h
#include <process.h
#include <string.h
#include <errno.h

volatile int ThreadRan;

void mythread(void arg)
{
ThreadRan = 1; / Flag the fact that we started /
sleep(1); / sleep a bit to work around Watcom problem /
} / with threads that end too quickly. */

int main(int argc, char *argv[])
{
int pid;

printf(“Parent pid: %d\n”,getpid());
fflush(stdout);

pid = _beginthread(mythread,NULL,32*1024,NULL);
if (pid == -1)
{
printf("_beginthread() failed, errno=%d, %s\n",errno,strerror
(errno));
exit(1);
}

printf(“Thread pid: %d\n”,pid);
fflush(stdout);

/* Wait to see if the thread really starts */
while (!ThreadRan)
sleep(1);

return 0;
}

7

“Mario Charest” <goto@nothingness.com> wrote in
news:abchat$e6r$1@inn.qnx.com:

Don’t know if it’s related to your problem but last time I checked,
sleep wasn’t thread safe.

Mario, you’re missing the point here:

THE THREAD NEVER GETS TO MY CODE!

Try this even simpler test case with the -3s compiler switch:

– test.c —

#include <stdio.h>
#include <process.h>

void mythread(void *arg)
{
}

int main(int argc, char argv[])
{
_beginthread(mythread,NULL,321024,NULL);
return 0;
}

cc test.c # default (register) calling
a.out # should work
cc -3s test.c # stack calling convention
a.out # will SEGV

Put a breakpoint on mythread() and it’ll never hit.

I’ve investigated further, and found that the Watcom begin_thread_healper()
routine in clib3s expects the thread argument to arrive on the stack, but
the tfork() routine sends it in register eax. I replaced the
begin_thread_helper() routine (found in the clib3s threadqnx module) and
everything works fine.

Ancient Deja searches show that a few other people have run across this
same issue, but every time they’ve asked for help they’ve gotten the same
sort of “threads are nasty” answers. At least Renee offered to try to
replicate the behavior, and I’m curious as to what happened there. Who
knows, maybe it’s a bad copy of the clib3s library on my QNX CD. Unlikely,
but possible.

I don’t suppose it matters anyway, since QSSL has clearly shown that they
aren’t interested in fixing QNX4/Watcom issues. Not that I blame them–
they’re full speed on RTP and I’d rather have most of their time go there
anyway. (I imagine we’ll be giving it another try when 6.2 finally
releases, but 6.1 was still a bit too rough around the edges for us on this
project.)

Anyway, sorry if I was a bit harsh above, Mario. I know that you’ve
provided good help to a lot of people on this group. And yes, I know that
multithreaded apps can be tricky and most (almost all?) problems are
really programmer errors. However, this one really is caused by a clib3s
bug.

Good call on the sleep() not being thread-safe. I had added it into the
test code because of a Watcom thread startup problem I seem to remember,
where threads that executed and returned too quickly caused some sort of
problem. I tossed in the sleep() to see if it would help, but then I
later realized that the SEGV was popping up before mythread() was even
called.

  • Larry
8

Welcome to the “stack calling convention” world Larry!
I’ve been using it for my XFree86 4.2 port for QNX4. see
http://www.sourceforge.net/projects/openqnx

Thoughout my work, I’ve found problems with the stack version
of the watcom libraries here and here. I don’t blame qssl,
not many people are using stack calling and those libs aren’t
being tested much. The good news is I’ve got good help from
qssl and got those libs fixed. The XFree86 port work initially
started back in 1996 when there was no QNX RTP and QNX4 was well
supported… Now the good old days are over …

Now back to your problem, there is a bug in tfork for the
stack calling convention and I do have fixed (from qssl).
but I don’t think I can send you the new version of the libary.

I tried your example and it sigsegv with the orginal lib and works
fine with the new lib.

The bottom line is you found a bug in QNX4/Watcom lib! and I can’t
help you :frowning:

Frank


Larry Martin <Larry@syatech-no-spam-here.com> wrote:

_beginthread() calls using stack calling convention (-5s) cause a SEGV, but
calls using register calling convention (-5s) work fine. I’m using a
trivial test program that just calls _beginthread(), sleeps, and exits,
with the second thread just sleeping and exiting too.

QNX4.25, Watcom 10.6

Has anyone else run across this? Is there a patch/workaround?

Unfortunately I need to use the stack calling convention to link to some
existing libraries. I suppose I could rewrite to use a fork() and shared
memory, but I’d rather hear about a fix/workaround. > :slight_smile:

Thanks,

  • Larry
9

“Larry Martin” <Larry@syatech-no-spam-here.com> wrote in message
news:Xns92096B18613C7Larrysyatechcom@209.226.137.7…

“Mario Charest” <> goto@nothingness.com> > wrote in
news:abchat$e6r$> 1@inn.qnx.com> :

Don’t know if it’s related to your problem but last time I checked,
sleep wasn’t thread safe.

Mario, you’re missing the point here:

THE THREAD NEVER GETS TO MY CODE!

I know Martin :wink: But when I post stuff here I know other people
are reading them. Hence sometimes I post not directly about the problem
at hand (as I cannot help you on that one) but to provide related
information for the general public :wink:

People may look at your code and thing that it is alright to use sleep in
multi-threaded applicatin under QNX4, mainly after you mentionned
being familliar with QNX4 threading.

So the best I can do on that one was catching the sleep(), sorry :wink:

Good luck!

10

<fliu@bb.vipstage.com> wrote in news:abe9u4$o54$1@inn.qnx.com:

Thoughout my work, I’ve found problems with the stack version
of the watcom libraries here and here.

[snip]

Now back to your problem, there is a bug in tfork for the
stack calling convention and I do have fixed (from qssl).
but I don’t think I can send you the new version of the libary.

I tried your example and it sigsegv with the orginal lib and works
fine with the new lib.

Thanks for confirming this. I was able to work around the tfork() bug by
replacing the begin_thread_helper() routine in the clib3s library with my
own version. After hearing your story I’m a bit worried about other hidden
bugs that might bite us. I supposed I’d better put in a call to QSSL and
see if I can get the fixed library you mentioned.

Thanks for the feedback,

  • Larry