After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 168352 - child-test with problems on HPUX
child-test with problems on HPUX
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.6.x
Other HP-UX
: Normal major
: ---
Assigned To: gtkdev
gtkdev
: 161746 168144 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-02-24 07:23 UTC by martin01
Modified: 2011-02-18 16:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description martin01 2005-02-24 07:23:09 UTC
glib-2.6.2 on HPUX 11.00 

mzfem_root:/data/GARNOME/garnome-2.6.2/platform/glib/work/main.d/glib-2.6.2/tests
# /usr/local/pa20_
32/bin/gcc -v
Reading specs from /usr/local/pa20_32/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.3.3/specs
Configured with: ../src/configure --enable-languages=c,c++
--prefix=/usr/local/pa20_32 --with-local-
prefix=/usr/local/pa20_32 --with-gnu-as --with-as=/usr/local/pa20_32/bin/as
--with-ld=/usr/ccs/bin/l
d --disable-shared --disable-nls
Thread model: single
gcc version 3.3.3

child test results:

creating uri-test
PASS: atomic-test
PASS: array-test
PASS: cxx-test
child 17066 (ttl 10) exited, status 0
child 17067 (ttl 20) exited, status 0
PASS: child-test
PASS: completion-test
PASS: date-test
PASS: dirname-test

** (process:17096): WARNING **: g_mkstemp works even if template doesn't end in
XXXXXX
PASS: file-test
PASS: env-test
gio-test: child writing 8+1297 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 1297 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+185 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 185 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+1076 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 1076 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+836 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 836 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+277 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 277 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+2003 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 2003 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+1876 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 1876 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+2971 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 2971 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+867 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 867 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+3216 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 3216 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+4732 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 4732 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+3369 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 3369 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+632 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 632 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+1898 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 1898 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+3124 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 3124 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+121 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 121 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+1066 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 1066 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+3453 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 3453 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+744 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 744 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+4940 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 4940 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+2280 bytes to 6
gio-test: ...from 5: IN
gio-test: ...from 5: 2280 bytes
gio-test: ...from 5: OK
gio-test: child writing 8+3964 bytes to 6
gio-test: child exiting, closing 6
gio-test: ...from 5: IN
gio-test: ...from 5: 3964 bytes
gio-test: ...from 5: OK
gio-test: ...from 5: IN
gio-test: ...from 5: EOF
PASS: gio-test
PASS: hash-test
 BLOCKING FALSE

Line one
Line two
Line three
/* Hello */
\x1234\x567890\x6666
read 62 bytes, wrote 62 bytes
PASS: iochannel-test
/bin/sh: 17143 Memory fault(coredump)
FAIL: keyfile-test
PASS: list-test

GThread-ERROR **: file gthread-posix.c: line 304 (): error 'Function is not
available' during 'pthre
ad_attr_init (&attr)'
aborting...
/bin/sh: 17162 Abort(coredump)
FAIL: mainloop-test
PASS: markup-escape-test
PASS: module-test
PASS: node-test
PASS: option-test
PASS: patterntest
PASS: printf-test
seed: 1109229041
PASS: queue-test
PASS: qsort-test
PASS: rand-test
PASS: relation-test
PASS: shell-test
PASS: slist-test
The following errors are supposed to occur:
Error (normal, supposed to happen): Failed to execute child process
"nonexistent_application" (No su
ch file or directory)
Error (normal, supposed to happen): Failed to execute child process
"nonexistent_application" (No su
ch file or directory)
Errors after this are not supposed to happen:
PASS: spawn-test
PASS: strfunc-test
PASS: string-test
PASS: strtod-test

GThread-ERROR **: file gthread-posix.c: line 304 (): error 'Function is not
available' during 'pthre
ad_attr_init (&attr)'
aborting...
/bin/sh: 17320 Abort(coredump)
FAIL: thread-test

GThread-ERROR **: file gthread-posix.c: line 304 (): error 'Function is not
available' during 'pthre
ad_attr_init (&attr)'
aborting...
/bin/sh: 17330 Abort(coredump)
FAIL: threadpool-test
PASS: tree-test
PASS: type-test
Cannot set locale to tr_TR, skipping
Cannot set locale to tr_TR, skipping
Cannot set locale to tr_TR, skipping
Cannot set locale to tr_TR.UTF-8, skipping
Cannot set locale to tr_TR.UTF-8, skipping
Cannot set locale to tr_TR.UTF-8, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
Cannot set locale to lt_LT.UTF-8, skipping
PASS: unicode-caseconv
PASS: unicode-encoding
PASS: utf8-validate
......................................................................................
PASS: uri-test
Test failed: unexpected error on ./markups/fail-1.gmarkup
FAIL: run-markup-tests.sh
=====================================================================
5 of 40 tests failed
Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=glib
=====================================================================
make: *** [check-TESTS] Error 1
mzfem_root:/data/GARNOME/garnome-2.6.2/platform/glib/work/main.d/glib-2.6.2/tests #
Comment 1 martin01 2005-02-24 07:29:48 UTC
fogot to tell, that the child-test only runs, if I take this patch for glib-
2.6.2

--- gmain.c.cln 2005-02-23 09:23:15.000000000 +0100
+++ gmain.c     2005-02-23 09:26:50.000000000 +0100
@@ -3579,7 +3579,11 @@

   action.sa_handler = g_child_watch_signal_handler;
   sigemptyset (&action.sa_mask);
-  action.sa_flags = SA_RESTART | SA_NOCLDSTOP;
+#ifdef __hpux
+  action.sa_flags = SA_NOCLDSTOP;
+#else
+   action.sa_flags = SA_RESTART | SA_NOCLDSTOP;
+#endif
   sigaction (SIGCHLD, &action, NULL);
 }

@@ -3644,7 +3648,11 @@

   action.sa_handler = g_child_watch_signal_handler;
   sigemptyset (&action.sa_mask);
-  action.sa_flags = SA_RESTART | SA_NOCLDSTOP;
+#ifdef __hpux
+  action.sa_flags = SA_NOCLDSTOP;
+#else
+   action.sa_flags = SA_RESTART | SA_NOCLDSTOP;
+#endif
   sigaction (SIGCHLD, &action, NULL);
 }
Comment 2 Sebastian Wilhelmi 2005-02-24 20:20:03 UTC
It seems, SA_RESTART on HP/UX also lets the select call be restarted after the
interrupt. This might very well be allowed by POSIX (I have no idea). Is there
any special reason, we use SA_RESTART anyway? I would propose dropping it
completely.
Comment 3 Sebastian Wilhelmi 2005-02-24 20:21:00 UTC
*** Bug 168144 has been marked as a duplicate of this bug. ***
Comment 4 Sebastian Wilhelmi 2005-02-24 20:21:53 UTC
*** Bug 161746 has been marked as a duplicate of this bug. ***
Comment 5 Matthias Clasen 2005-02-24 20:37:57 UTC
SA_RESTART was introduced when we changed from signal() to sigaction(), presumably
because it makes sigaction "behaviour compatible with BSD signal semantics".

The bug leading to that change is bug 136867.
Comment 6 Sebastian Wilhelmi 2005-02-25 15:09:24 UTC
> SA_RESTART was introduced when we changed from signal() to sigaction(), 
> presumably because it makes sigaction "behaviour compatible with BSD signal 
> semantics".

Yes, but nobody can go on and expect stdlib functions to not return EINTR, can he?
So why even bother. You mean, because of backward compatibilty? I don't think,
we ever guaranteed that, so just completly drop SA_RESTART.
Comment 7 martin01 2005-02-25 15:16:56 UTC
Patch for mainloop-test.c:
==========================

--- mainloop-test.c.cln 2005-02-25 15:42:14.000000000 +0100
+++ mainloop-test.c     2005-02-25 15:55:37.000000000 +0100
@@ -410,6 +410,7 @@

   main_loop = g_main_loop_new (NULL, FALSE);

+#ifndef __hpux
   for (i = 0; i < NTHREADS; i++)
     create_adder_thread ();

@@ -429,6 +430,7 @@

   g_main_loop_run (main_loop);
   g_main_loop_unref (main_loop);
+#endif

 #endif
   return 0;

Patch for threadpool-test.c:
============================

--- threadpool-test.c.cln       2005-02-25 16:03:24.000000000 +0100
+++ threadpool-test.c   2005-02-25 16:03:59.000000000 +0100
@@ -35,6 +35,7 @@
   guint i;
   g_thread_init (NULL);

+#ifndef __hpux
   pool1 = g_thread_pool_new (thread_pool_func, NULL, 3, FALSE, NULL);
   pool2 = g_thread_pool_new (thread_pool_func, NULL, 5, TRUE, NULL);
   pool3 = g_thread_pool_new (thread_pool_func, NULL, 7, TRUE, NULL);
@@ -53,5 +54,6 @@
   g_assert (RUNS * 3 == abs_thread_counter);
   g_assert (running_thread_counter == 0);
 #endif
+#endif
   return 0;
 }
Comment 8 Matthias Clasen 2005-02-25 15:20:14 UTC
Sebastian, if removing SA_RESTART makes the code work on all platforms, I'm all
for it. I have no strong opinion on this, apart from the general feeling that
using signals really sucks.
Comment 9 Manish Singh 2005-02-25 17:15:44 UTC
Or that HP/UX really sucks....
Comment 10 The Written Word 2005-02-25 17:36:19 UTC
I emailed the hpux developer tools list asking about SA_RESTART and select()
(comment #2).
Comment 11 The Written Word 2005-02-25 19:17:09 UTC
Got some feedback from the hpux-devtools mailing list.

From select(2) on HP-UX 11i:
           [EINTR]        The select() function was interrupted  before any
                          of the selected events occurred and before the
                          timeout interval expired. If SA_RESTART has been
                          set for the interrupting signal, it is
                          implementation-dependent whether select() restarts
                          or returns with EINTR.

Doesn't say what HP-UX does but if it's implementation-dependent, seems we
cannot rely on it.

Got the following response as well:
  Here's what Stevens has to say about the general issue of SA_RESTART
  and select() in his book UNIX Networking Programming, Volume 1:
   
      Berkeley-derived kernels never automatically restart select
      (p. 527 of TCPv2), while SVR4 will if the SA_RESTART flag is
      specified when the signal handler is installed.  This means
      that for portability we must be prepared for select to return
      an error of EINTR if we are catching signals.
Comment 12 Martin01 2005-02-25 20:00:21 UTC
here is a nother discussion 'Problem with system() calls in a multithreaded
program on HPUX 11'

http://www.webservertalk.com/message919224.html
Comment 13 Matthias Clasen 2005-04-01 21:41:24 UTC
2005-04-01  Matthias Clasen  <mclasen@redhat.com>

	* glib/gmain.c (g_child_watch_source_new): Add a note regarding
	waitpid(-1).
	(g_child_watch_source_init_multi_threaded): 
	(g_child_watch_source_init_single): Don't use SA_RESTART,
	since it causes problems on at least one platform. (#168352)