This seems to be generic problem of regcomp.

vcl project is now completely buildable, so I'm trying to compile svdem in
workben to test it:

oo@marvin:~/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/vcl/workben> dmake
-------------
rm -f ../unxlngx4.pro/bin/applicat.rdb
cp
/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/bin/types.rdb
../unxlngx4.pro/bin/applicat.rdb
cd ../unxlngx4.pro/bin && \
                regcomp -register -r applicat.rdb \
                        -c i18nsearch.uno.so \
                        -c i18npool.uno.so
Segmentation fault
dmake:  Error code 139, while making '../unxlngx4.pro/bin/applicat.rdb'
dmake:  '../unxlngx4.pro/bin/applicat.rdb' removed.
---* TG_SLO.MK *---
oo@marvin:~/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/vcl/workben> 

regcomp's SIGSEGV in vcl:

oo@marvin:~/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/vcl/unxlngx4.pro/bin> gdb
regcomp
GNU gdb 5.3.92
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...(no debugging symbols found)...
(gdb) run -register -r applicat.rdb                         -c i18nsearch.uno.so
                        -c i18npool.uno.so
Starting program:
/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/bin/regcomp
-register -r applicat.rdb                         -c i18nsearch.uno.so         
               -c i18npool.uno.so
setenv: Too many arguments.
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 16384 (LWP 1631)]
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1631)]
0x0000002a95ac902d in
cppu::WeakAggComponentImplHelper_getTypes(cppu::class_data*) ()
   from
/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/lib/libcppuhelpergcc3.so.3
(gdb) where
#0  0x0000002a95ac902d in
cppu::WeakAggComponentImplHelper_getTypes(cppu::class_data*) ()
   from
/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/lib/libcppuhelpergcc3.so.3
#1  0x0000002a95ac85bb in cppu::WeakImplHelper_query(com::sun::star::uno::Type
const&, cppu::class_data*, void*, cppu::OWeakObject*) ()
   from
/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/lib/libcppuhelpergcc3.so.3
#2  0x0000002a96959468 in component_getFactory ()
   from
/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/lib/simplereg.uno.so
#3  0x000000000040b94e in
com::sun::star::uno::Reference<com::sun::star::registry::XSimpleRegistry>::Reference(com::sun::star::uno::BaseReference
const&, com::sun::star::uno::UnoReference_Query) ()
#4  0x000000000040a177 in DoIt::operator()(rtl::OUString const&) ()
#5  0x000000000040aa7f in main ()
(gdb) 

The same problem is in cppuhelper's test directory:

oo@marvin:~/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/cppuhelper/test> dmake
idlc -I..
-I/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/idl
-O../unxlngx4.pro/bin ./helpertest.idl
idlc: compile './helpertest.idl' ... 
idlc: returned successful
Sun Microsystems (R) idlc Version 1.1

regmerge ../unxlngx4.pro/bin/cpputest.rdb /UCR ../unxlngx4.pro/bin/helpertest.urd
regmerge ../unxlngx4.pro/bin/cpputest.rdb /
/abuild/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/solver/680/unxlngx4.pro/bin/udkapi.rdb
regcomp -register -r ../unxlngx4.pro/bin/cpputest.rdb -c reflection.uno.so
Segmentation fault
dmake:  Error code 139, while making '../unxlngx4.pro/bin/cpputest.rdb'
dmake:  '../unxlngx4.pro/bin/cpputest.rdb' removed.
---* TG_SLO.MK *---
oo@marvin:~/oo/BuildDir/ooo_cws_src680_ooo64bit02_src/cppuhelper/test> 

I open the debug swich and get lines that is the end of the output information:

Trace Message: /home/jjh/OOo/debug64/sal/rtl/source/bootstrap.cxx --
Bootstrap_Impl::getValue() - name:UNO_AC_USERCACHE_SIZE value:

osl_getsymbol: got Symbol initRegistry_Api
Segmentation fault
dmake:  Error code 139, while making '../../unxlngx4.pro/lib/pyuno_services.rdb'
---* TG_SLO.MK *---

I modify the file OO~/solver/680/unxlngx4.pro/inc/com/sun/star/uno/Type.h to
inline TypeClass SAL_CALL getTypeClass() const SAL_THROW( () )
                {
                        OSL_TRACE(
        __FILE__" getTypeClass()%d  %d\n ",(int)SAL_MAX_ENUM,sizeof(size_t) );
                        OSL_TRACE(
        __FILE__" getTypeClass() _pType->eTypeClass %d\n ",_pType );
                        TypeClass  temp = (TypeClass)_pType->eTypeClass;
//                       return (TypeClass)_pType->eTypeClass;
                        OSL_TRACE(
        __FILE__" getTypeClass()_pType->eTypeClass \n " );
                        return temp;
                }

and build the pyuno
get the information:
Trace Message:
/home/jjh/OOo/debug64/solver/680/unxlngx4.pro/inc/com/sun/star/uno/Type.h
getTypeClass() _pType->eTypeClass 3

Segmentation fault
dmake:  Error code 139, while making '../../unxlngx4.pro/lib/pyuno_services.rdb'
---* TG_SLO.MK *---

ERROR: Error 65280 occurred while making /home/jjh/OOo/debug64/pyuno/source/loader

3 is the address of _pType. It is an valid address 
I think the segment fault because this.
but now I did not kown how to correct it.

Hi Pavel, I will take a look next week, when I am back in Hamburg. Hope that's 
ok for you.

I traced the code and and found the segment fault caused from the code in
cppu/inc/com/sun/star/uno/Reference.hxx.
In the function:
template< class interface_type >
inline XInterface * Reference< interface_type >::iquery(
        XInterface * pInterface ) SAL_THROW( (RuntimeException) )
{
    return BaseReference::iquery(
        pInterface, ::getCppuType( (const Reference< interface_type > *)0) );
}

the code: ::getCppuType( (const Reference< interface_type > *)0) got and invalid
pointer
and The getCppuType called the function in cpputools/unxlngx4.pro/inc/
then I check the XSimpleRegistry.hpp and XComponent.hpp it different from the
files in the solver/680/unxlngx4.pro/inc. Then I copy the files from solver to
cpputools.
and regcomp work!!!!!!!!!

at last I check the makefile in cpputools/source/registercomponent and
cpputools/source/regsingleton. just delete the -C flag. this is the diff in
registercomponent:
--- makefile.mk 2004-07-16 13:06:49.000000000 +0800
+++ makefile.mk.bak     2004-07-16 13:06:39.000000000 +0800
@@ -75,7 +75,7 @@

 UNOUCROUT = $(OUT)$/inc$/$(TARGET)
 INCPRE += $(UNOUCROUT)
-CPPUMAKERFLAGS =
+CPPUMAKERFLAGS += -C

 UNOTYPES=\
                        com.sun.star.uno.TypeClass \

this is the diff in regsingleton:
--- makefile.mk 2004-07-16 13:07:11.000000000 +0800
+++ makefile.mk.bak     2004-07-16 13:07:04.000000000 +0800
@@ -76,7 +76,7 @@

 UNOUCROUT = $(OUT)$/inc$/$(TARGET)
 INCPRE += $(UNOUCROUT)
-CPPUMAKERFLAGS=
+CPPUMAKERFLAGS+= -C

 UNOTYPES= \
        com.sun.star.uno.TypeClass \

I traced the code and and found the segment fault caused from the code in
cppu/inc/com/sun/star/uno/Reference.hxx.
In the function:
template< class interface_type >
inline XInterface * Reference< interface_type >::iquery(
        XInterface * pInterface ) SAL_THROW( (RuntimeException) )
{
    return BaseReference::iquery(
        pInterface, ::getCppuType( (const Reference< interface_type > *)0) );
}

the code: ::getCppuType( (const Reference< interface_type > *)0) got and invalid
pointer
and The getCppuType called the function in cpputools/unxlngx4.pro/inc/
then I check the XSimpleRegistry.hpp and XComponent.hpp it different from the
files in the solver/680/unxlngx4.pro/inc. Then I copy the files from solver to
cpputools.
and regcomp work!!!!!!!!!

at last I check the makefile in cpputools/source/registercomponent and
cpputools/source/regsingleton. just delete the -C flag. this is the diff in
registercomponent:
--- makefile.mk 2004-07-16 13:06:49.000000000 +0800
+++ makefile.mk.bak     2004-07-16 13:06:39.000000000 +0800
@@ -75,7 +75,7 @@

 UNOUCROUT = $(OUT)$/inc$/$(TARGET)
 INCPRE += $(UNOUCROUT)
-CPPUMAKERFLAGS =
+CPPUMAKERFLAGS += -C

 UNOTYPES=\
                        com.sun.star.uno.TypeClass \

this is the diff in regsingleton:
--- makefile.mk 2004-07-16 13:07:11.000000000 +0800
+++ makefile.mk.bak     2004-07-16 13:07:04.000000000 +0800
@@ -76,7 +76,7 @@

 UNOUCROUT = $(OUT)$/inc$/$(TARGET)
 INCPRE += $(UNOUCROUT)
-CPPUMAKERFLAGS=
+CPPUMAKERFLAGS+= -C

 UNOTYPES= \
        com.sun.star.uno.TypeClass \

*** Issue 30397 has been marked as a duplicate of this issue. ***

jianhuajiao: could you please attach patch that fixes this problem? What changes
you did exactly?

Please usee diff -u old new and not diff -u new old because diff should describe
changes you have to apply to old file to get new one :-)

I'd like to catch with you in the build issue, but I'd also like to fix all
issues properly in our cws so others can follow us. Please help me with that.

sorry I did it reversed.
two way to deal the trouble.
1. copy the files XSimpleRegistry.hpp and XComponent.hpp from
solver/680/unxlngx4.pro/inc to cpputools/unxlngx4.pro/inc.
2. diff -u cpputools/source/registercomponent/makefile.mk.bak
cpputools/source/registercomponent/makefile.mk

-- cpputools/source/registercomponent/makefile.mk.bak  2004-07-16
13:06:39.000000000 +0800
+++ cpputools/source/registercomponent/makefile.mk      2004-07-16
13:06:49.000000000 +0800
@@ -75,7 +75,7 @@

 UNOUCROUT = $(OUT)$/inc$/$(TARGET)
 INCPRE += $(UNOUCROUT)
-CPPUMAKERFLAGS += -C
+CPPUMAKERFLAGS =

 UNOTYPES=\
                        com.sun.star.uno.TypeClass \

and diff -u cpputools/source/regsingleton/makefile.mk.bak
cpputools/source/regsingleton/makefile.mk

--- cpputools/source/regsingleton/makefile.mk.bak       2004-07-16
13:07:04.000000000 +0800
+++ cpputools/source/regsingleton/makefile.mk   2004-07-16 13:07:11.000000000 +0800
@@ -76,7 +76,7 @@

 UNOUCROUT = $(OUT)$/inc$/$(TARGET)
 INCPRE += $(UNOUCROUT)
-CPPUMAKERFLAGS+= -C
+CPPUMAKERFLAGS=

 UNOTYPES= \
        com.sun.star.uno.TypeClass \


the reason just say above.
and this is not last fixed the issue. because the makefile.mk and *.hpp are auto
generated.

Daniel, could you please take a look why "comprehensive" segfaults?

Well, how to reproduce this here without having any Opteron inhouse? ;)
Seems strange to me, -C ought not do any harm at all. So guys, please try to get
a better stack , maybe it helps to outline some functions in
cppuhelper/source/implbase_ex.cxx, namely all __ prefixed functions; better for
gcc stacks.

this is not only opteron, it is reproduced on sunblade 100 sun4u linux sparc
debian/unstable see issue 31057. removing the -C does work too.

@sparcmoz: well, this is issue 31057, maybe you think of a different issue? Even
though, I don't know of any linux sparc installation here inhouse, so please
provide a better stack for this.

@dbo: sorry, i meant 30397. anyway to get a better backtrace i did build
cppuhelper with debug=true and now there is no segfault!! many assertions fail,
see attached. i will get the segfault backtrace soon.

Created attachment 16910 [details]
build cppuhelper debug=true

@dbo: to get this bus error i did only re-build cppuhelper without debug

(gdb) run
Starting program: /home/jim/680/solver/680/unxlngs.pro/bin/regcomp -register -r
pyuno_services.tmp -c typeconverter.uno -c invocation.uno -c reflection.uno -c
introspection.uno -c invocadapt.uno -c proxyfac.uno -c pythonloader.uno
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 8707)]

Program received signal SIGBUS, Bus error.
[Switching to Thread 16384 (LWP 8707)]
0x7026dd10 in cppu::WeakImplHelper_query ()
   from /home/jim/680/solver/680/unxlngs.pro/lib/libcppuhelpergcc3.so.3
(gdb) bt
#0  0x7026dd10 in cppu::WeakImplHelper_query ()
   from /home/jim/680/solver/680/unxlngs.pro/lib/libcppuhelpergcc3.so.3
#1  0x7077763c in component_getFactory ()
   from /home/jim/680/solver/680/unxlngs.pro/lib/simplereg.uno.so
#2  0x0001f9d4 in com::sun::star::uno::BaseReference::iquery (
    pInterface=0x702c4ac0, rType=@0x702bfa20) at Reference.hxx:93
#3  0x0001edbc in
com::sun::star::uno::Reference<com::sun::star::registry::XSimpleRegistry>::iquery
(pInterface=0x702c4ac0) at Reference.hxx:108
#4  0x0001d840 in Reference (this=0xefffe360, rRef=@0xefffe368)
    at Reference.hxx:182
#5  0x0001b7cc in bootstrap (opt=@0xefffe4b0, xSMgr=@0xefffe4a0,
    reg=@0xefffe498)
    at /home/jim/680/cpputools/source/registercomponent/registercomponent.cxx:677
#6  0x0001c548 in main (argc=18, argv=0xefffe5a4)
    at /home/jim/680/cpputools/source/registercomponent/registercomponent.cxx:771
(gdb)

@sparcmoz: maybe the inlining does not work properly, please try to outline the
mentioned __ functions in cppuhelper/source/implbase_ex.cxx. Then build
cppuhelper (without debug) and try again.

outlining does not solve the problem. 

without any chnages, but building BOTH pyuno and cppuhelper with debug=true does
seem to allow the build. 

i need to investigate more...

@sparcmoz: Can you try to build _without_ debug=true, but in the
solenv/inc/unxlngs*.mk files, change the default optimization to -O1.  If that
still segfaults, change it to -O0 and post the results here.  I assume you're
trying 64-bit Sparc Debian Linux port?

Cheers,
Dan

do you check the return value of
::getCppuType( (const Reference< interface_type > *)0)
in cppu/inc/com/sun/star/uno/Reference.hxx?

When I use the return value, just get a segment fault.

and when I removed the -C option and compiled cpputools but it did not compiled
the testtools. a segment faoult is there yet.

@fa: 
linux sparc not s64 bit
-----------------------
i got this problem in 32 bit building. linux sparc userland is 32 bit, the
general view appears to be "64bit needs a lot of work and probably runs slower"
but i have no idea, maybe it is just not enough developers. all my files are 32
bit like this eg: implbase_ex.o: ELF 32-bit MSB relocatable, SPARC, version 1
(SYSV), not stripped

cppuhelper and pyuno with -O1
-----------------------------
t.uno -c proxyfac.uno -c pythonloader.uno
Bus error
dmake:  Error code 138, while making '../../unxlngs.pro/lib/pyuno_services.rdb'
---* tg_merge.mk *---

cppuhelper and pyuno with -O0
-----------------------------
Making: ../../unxlngs.pro/lib/ipythonloader.uno.lib
no ImportLibs on Mac and *ix
-------------
cp pythonloader.py ../../unxlngs.pro/lib/pythonloader.py
rm -f ../../unxlngs.pro/lib/pyuno_services.rdb
../../unxlngs.pro/lib/pyuno_services.tmp ../../unxlngs.pro/lib/pyuno_services.rdb
cd ../../unxlngs.pro/lib && regcomp -register -r pyuno_services.tmp -c
typeconverter.uno -c invocation.uno -c reflection.uno -c introspection.uno -c
invocadapt.uno -c proxyfac.uno -c pythonloader.uno
register component 'typeconverter.uno' in registry 'pyuno_services.tmp' succesful!
register component 'invocation.uno' in registry 'pyuno_services.tmp' succesful!
register component 'reflection.uno' in registry 'pyuno_services.tmp' succesful!
register component 'introspection.uno' in registry 'pyuno_services.tmp' succesful!
register component 'invocadapt.uno' in registry 'pyuno_services.tmp' succesful!
register component 'proxyfac.uno' in registry 'pyuno_services.tmp' succesful!
register component 'pythonloader.uno' in registry 'pyuno_services.tmp' succesful!
cd ../../unxlngs.pro/lib && mv pyuno_services.tmp pyuno_services.rdb
jim@sun:~/680/pyuno$

Maybe this can be worked around using NOOPTFILES such as i had to do several
places in calc? Just need isolate the problem files, some guesswork or a binary
search can do it.

@jianhuajiao: i have got a similar problem running testcppu too, so there is
more yet to follow up. 

@sparcmoz: in cws_src680_ooo64bit02 compiled cppu/test no this problem if
removed the -C option.

update: on a x86_64 recomp works with with cppuhelper compiled with -O0, it does
not with -O1 (gcc 3.3.3).

On linux sparc cws_src680_ooo20040815 rebuilding both modules with -O2, pyuno
now builds ok with this patch 

Index: source/makefile.mk
===================================================================
RCS file: /cvs/udk/cppuhelper/source/makefile.mk,v
retrieving revision 1.35
diff -u -u -r1.35 makefile.mk
--- source/makefile.mk  4 Jun 2004 03:21:42 -0000       1.35
+++ source/makefile.mk  4 Aug 2004 21:48:27 -0000
@@ -201,6 +201,8 @@
 SHL1VERSIONMAP=gcc2_linux_intel.map
 .ELIF "$(OS)$(CPU)$(COMNAME)"=="FREEBSDIgcc3"
 SHL1VERSIONMAP=gcc3_linux_intel.map
+.ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXSgcc3"
+SHL1VERSIONMAP=gcc3_linux_intel.map
 .ENDIF

mh: so do you think this is compiler issue?

.

The problem must be deal well. I build instoo project by skipping some trouble.
And I installed the openoffice.org. A crash produced same as this segment fault
-- I catch the trace. And by modifying the makefile, not only removed the -C but
using -CS, the regcomp both worked. 

I use the patch for cppuhelper in ooo64bit02.the diff is 
diff -u makefile.mk.bak makefile.mk

--- makefile.mk.bak     2004-08-20 16:38:15.000000000 +0800
+++ makefile.mk 2004-08-20 16:32:16.000000000 +0800
@@ -201,6 +201,8 @@
 SHL1VERSIONMAP=gcc2_linux_intel.map
 .ELIF "$(OS)$(CPU)$(COMNAME)"=="FREEBSDIgcc3"
 SHL1VERSIONMAP=gcc3_linux_intel.map
+.ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXXgcc3"
+SHL1VERSIONMAP=gcc3_linux_intel.map
 .ENDIF

 # --- Targets ------------------------------------------------------


but now when I use the cppumaker option -C, -CS or removed -C from
cpputools/source/registercomponent/makefile.mk

get new error --not segment fault:

rm -f ../../unxlngx4.pro/lib/pyuno_services.rdb
../../unxlngx4.pro/lib/pyuno_services.tmp ../../unxlngx4.pro/lib/pyuno_services.rdb
cd ../../unxlngx4.pro/lib && regcomp -register -r pyuno_services.tmp -c
typeconverter.uno -c invocation.uno -c reflection.uno -c introspection.uno -c
invocadapt.uno -c proxyfac.uno -c pythonloader.uno
ERROR: create ServiceManager failed!
ERROR description: loading component library failed:
file:///home/jjh/OOo/amd64/solver/680/unxlngx4.pro/lib/servicemgr.uno.so
dmake:  Error code 1, while making '../../unxlngx4.pro/lib/pyuno_services.rdb'
---* TG_SLO.MK *---

I don't know why.

mh: confirmed, with -O0, pyuno is successfully registered.
Hmm.

I don't see anything to fix in cppuhelper right now (maybe I am wrong), because
when switching off optimization (-O0), it works. For me, this seems to be a
compiler issue.
Thus I will pass that issue back to you, Pavel. Any further comments, ideas?

I've done the following to further identify the piece of code that is miscompiled:

I compiled everything with -O0 and verified that pyuno builds correctly.

I changed the unxlngx*mk to use -O1 from now on and touch file by file in
cppuhelper/source/.

Finally I have everything compiled with -O0 and only component.cxx compiled with
-O1. And it SIGSEGV's -> component.cxx is miscompiled.

I'll investigate this further when back from OOoCon. Maybe we can look at it at
OOoCon remotely ;-)

I use gcc-3.3.3. I'll try 3.3.4 and probably also 3.4.x, but this need
additional patches on this branch, probably :-(

This is completely the same with

Reading specs from
/tmp/gcc-3.3.4/bin/../lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.4/specs
Configured with: ./configure --prefix=/tmp/gcc-3.3.4/
Thread model: posix
gcc version 3.3.4

ie. if component.cxx is compiled with -O0, it works.

Hi,

you might have a look at the final solution of 

http://www.openoffice.org/issues/show_bug.cgi?id=35682

, as this might be also the source of this problem ...

Bye,

Joerg

I updated gcc to 3.4.1, but it doesn't help.

The same with 3.4.3.

is this still happening? It might be related to 
http://www.openoffice.org/issues/show_bug.cgi?id=35064 ??
Someone who can verify that it works now with ooo64bit02 ?

kendy, Martin: this is the bug we were looking for ;-)

WORKSFORMENOW

.