Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote:
Hi all,
Rev. 1.20 of src/lib/libc_r/uthread/uthread_join.c still breaks
Openoffice build.
During the build, the idl compiler from sun just hangs, and stays
there in the endless loop.
+ while (_thread_run-join_status.thread == pthread) {
+ /* Schedule the next thread: */
+ _thread_kern_sched_state(PS_JOIN, __FILE__, __LINE__);
+ }
This loop is correct, like I've said twice before.
The same idlc code works fine in Solaris, Linux, and NetBSD (they do
not have threads).
So it is definitly a FreeBSD libc_r bug.
Did you even try the patch I sent you to uthread_detach.c?
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
Hi, This loop is correct, like I've said twice before. Did you even try the patch I sent you to uthread_detach.c? I've not recieved any patch. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote:
Hi Daniel,
Unfortunatly the patch doesn't work ...
Try adding this patch also (keep other patch in):
Index: uthread_cancel.c
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_cancel.c,v
retrieving revision 1.11
diff -u -r1.11 uthread_cancel.c
--- uthread_cancel.c16 Dec 2001 13:26:44 - 1.11
+++ uthread_cancel.c6 Mar 2002 16:57:18 -
@@ -70,6 +70,9 @@
if (pthread-join_status.thread != NULL) {
pthread-join_status.thread-joiner
= NULL;
+ pthread-join_status.thread = NULL;
+ pthread-join_status.ret = NULL;
+ pthread-join_status.error = 0;
}
pthread-cancelflags |= PTHREAD_CANCELLING;
PTHREAD_NEW_STATE(pthread, PS_RUNNING);
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
and here is the output generated in /var/tmp -DSUPD=641 -DUPD=641 -I. -I.. -I../../../.. -I../../../../inc -I../../../../unxfbsd.pro/idl -I../../../../unxfbsd.pro/inc -I/usr/ports/editors/openoffice-work/work/oo_641c_src/solver/641/unxfbsd.pro/idl -I/usr/ports/editors/openoffice-work/work/oo_641c_src/solver/641/unxfbsd.pro/inc -O../../../../unxfbsd.pro/ucr/com/sun/star/lang ArrayIndexOutOfBoundsException.idl ClassNotFoundException.idl DisposedException.idl EventObject.idl IllegalAccessException.idl etc ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
hi Daniel, + pthread-join_status.thread = NULL; + pthread-join_status.ret = NULL; + pthread-join_status.error = 0; it still hangs :-( How should a detach routine in the client code look like ? Does the client have to catch a signal or something ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote: hi Daniel, + pthread-join_status.thread = NULL; + pthread-join_status.ret = NULL; + pthread-join_status.error = 0; it still hangs :-( Actually, the patch I gave you to uthread_detach was wrong. Here is the correct one (apply by hand if you have to). Index: uthread_detach.c === RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_detach.c,v retrieving revision 1.16 diff -u -r1.16 uthread_detach.c --- uthread_detach.c2001/05/20 23:08:32 1.16 +++ uthread_detach.c2002/03/06 19:00:17 @@ -66,7 +66,9 @@ PTHREAD_NEW_STATE(joiner, PS_RUNNING); /* Set the return value for the woken thread: */ - joiner-error = ESRCH; + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; /* * Disconnect the joiner from the thread being detached: How should a detach routine in the client code look like ? Does the client have to catch a signal or something ? No, there is no signal. BTW, if the code is expecting a signal to interrupt a join operation, it is wrong. A thread that is in a join can catch a signal, but if it returns from the signal handler normally (without longjmp'ing out of it) then it resumes the join operation. That is why there is a loop in uthread_join.c. It is to allow the thread to execute a signal handler and when it returns it will resume the join operation. Removing the loop breaks signal handling. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
Thanks Daniel ! + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; Oh wonder. It works no like a charm. :-)) Do you know in what case we can bump the osversion ? Is this one case we can do it so I could check the OSVERSION in the port ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote: Thanks Daniel ! + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; Oh wonder. It works no like a charm. :-)) OK, I just committed the fixes. Do you know in what case we can bump the osversion ? Is this one case we can do it so I could check the OSVERSION in the port ? I don't know enough about how and when OSVERSION is suppose to change to make that call. See if there is anything in the handbook about it. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, Mar 06, 2002 at 02:31:32PM -0500, Daniel Eischen wrote: On Wed, 6 Mar 2002, Martin Blapp wrote: Thanks Daniel ! + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; Oh wonder. It works no like a charm. :-)) OK, I just committed the fixes. Do you know in what case we can bump the osversion ? Is this one case we can do it so I could check the OSVERSION in the port ? I don't know enough about how and when OSVERSION is suppose to change to make that call. See if there is anything in the handbook about it. There's no harm in bumping OSVERSION frequently (but don't go overboard). If there's something out there which needs to differentiate between versions older and newer than a certain version of the OS, it's appropriate to bump OSVERSION. Kris msg32525/pgp0.pgp Description: PGP signature
