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 157312 - glib regression tests fail on AIX 4.3.2.0
glib regression tests fail on AIX 4.3.2.0
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: general
2.2.x
Other AIX
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2004-11-04 07:10 UTC by Winfried Harbecke
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Winfried Harbecke 2004-11-04 07:10:50 UTC
Trying to get Mono (www.go-mono.com) to run on powerpc-ibm-aix4.3.2.0,
I ran into failing regression tests in glib 2.2.1. The glib source tree
I am using is from http://aixpdslibs.seas.ulcla.edu (following instructions
in README.RS6K). I am using GCC 3.3.4, also generated from the source
tarball from http://aixpdslibs.seas.ulcla.edu as recommended by

	http://www-128.ibm.com/developerworks/eserver/articles/gnu.html	

(the binary GCC tarball did not work because of fixinclude incompatbilities)

The failing regression tests (3 of 29) are module-test, strfunc-test, and
strtod-test. The stack trace from strtod-test resembles the stack trace that
I get when I try to start the Mono interpreter.

module-test:
============ 
** ERROR **: error: global state should have been "global clash", but is "NULL"
aborting...
IOT/Abort trap(coredump)

Current directory is /home2/glib-2.2.1/tests/.libs/
Type 'help' for help.
reading symbolic information ...
[using memory image in ../core]

IOT/Abort trap in raise.raise [/usr/lib/libc.a] at 0xd01868a8
0xd01868a8 (raise+0x4c) 80410014        lwz   r2,0x14(r1)
(/usr/bin/dbx) where
raise.raise(??) at 0xd01868a8
abort.abort() at 0xd017f2f8
g_logv(0x0, 0x4, 0x10007ed0, 0x2ff22a04) at 0xd360f84c
g_log(0x0, 0x4, 0x10007ed0) at 0xd360f94c
compare(0x10007f04, 0x10007eb8, 0x0) at 0x10000448
test_states(0x10007eb8, 0x0, 0x0) at 0x100004b4
main(0x1, 0x2ff22b3c) at 0x100009d8
(/usr/bin/dbx) 


strfunc-test:
=============
(strfunc-test.c:449) failed for: 3 == g_snprintf (buf, 0, "%s", "abc")
Segmentation fault(coredump)

Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in printf.vsnprintf [/usr/lib/libc.a] at 0xd018ff80
0xd018ff80 (vsnprintf+0x6c) 7fc521ae       stbx   r30,r5,r4
(dbx) where
printf.vsnprintf(??, ??, ??, ??) at 0xd018ff80
g_vsnprintf(0x0, 0x0, 0x10010130, 0x2ff22abc) at 0xd3691f28
g_snprintf(0x0, 0x0, 0x10010130) at 0xd3691bb4
main(0x1, 0x2ff22b6c) at 0x10006274
(dbx) 

strtod-test:
============
Segmentation fault(coredump)

Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in ptrgl._ptrgl [/usr/lib/libc.a] at 0xd016ef90
0xd016ef90 (_ptrgl)    800b0000        lwz   r0,0x0(r11)
(dbx) where
ptrgl._ptrgl() at 0xd016ef90
setlocale.setlocale(??, ??) at 0xd018d430
test_string(0x1000820c, 2.7814021290411505e-309) at 0x100003b4
main() at 0x100004c0
(dbx)
Comment 1 Matthias Clasen 2004-11-05 16:19:25 UTC
These are segfaults inside the C library. Not much we can do if libc is broken...
we really need a working printf() and setlocale() implementation.
Comment 2 Winfried Harbecke 2004-11-08 08:49:53 UTC
Actually I suspect it is a GCC problem (the C library seems to expect a 
different stack layout than what GCC provides wjen compiling with 
option "pthread"). Currently, I am trying to recompile first the dependencies, 
then glib with the native AIX compiler. I was hoping the symptoms look familiar 
to someone who has worked on the glib AIX port.
Comment 3 Winfried Harbecke 2004-11-09 11:42:03 UTC
When compiling with IBM Visual Age C, I get the same crashes plus one more FAIL 
in thread-test. When running Visual Age against the glib 2.4.7 sources, the 
strfunc-test crash disappears. From superficially debugging strtod-test, I get 
the impression that either the stack or heap get corrupted, probably due to a 
name clash (a simple loop over setlocale calls - equivalently compiled and 
linked - does NOT crash).

Matthias - are you saying the segfaults are expected failurers? Are there any 
projects using glib that have reported a working AIX port? If both answers are 
NO, it would make sense for me to do some more debugging.
Comment 4 Matthias Clasen 2004-11-09 13:14:57 UTC
No, the stacktraces are not expected, but they do not look like something that
is caused by a programming error in glib. It could be bugs in the C library or
toolchain issues.
Comment 5 Matthias Clasen 2004-11-09 13:16:07 UTC
And to complete that comment, those are hard to debug without access to the
platform in question, so if you want to do some more debugging that would be
appreciated.
Comment 6 Winfried Harbecke 2004-11-23 10:04:47 UTC
There is some evidence supporting the diagnosis that the segmentation faults in 
glib
regression tests resulted from incorrectly linked shared/static libraries and 
executables:

	1) the crashes in strtod-test occurred in procedure descriptor
	dereferencing "glue" code, which differs between shared and static
        linking

	2) debugging the code preceeding the crash, I see a faulty procedure
	descriptor within setlocale(2)

	3) apparently there are two versions of setlocale linked into the
        binary, one from libc, the other from librtl

	4) strtod-test does not crash when executed in an AIX 5.1 (GCC,
        AIX as/ld) environment with binary or source glib from
	http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html
	and
	http://gnome.bullfreeware.com/new_index.html

			gettext-0.10.39-2
			zlib-1.1.4-1
			zlib-devel-1.1.4-1
			glib2-2.4.0-2
			glib2-devel-2.4.0-2

	5) the AIX toolbox README
	
	ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/README.txt
	indicates that glib had to be linked with run time linking enabled in
        order to handle circular library dependencies

Anyone working with the glib AIX port should consult the AIX fro LInux toolbox 
README and FAQ first. Also, the RPMs from gnome.bullfreeware.com make life a 
lot easier.