Issue 105359 - bridges:arm failure to start OOo - terminate called after throwing an instance of 'com::sun::star::ucb::InteractiveAugmentedIOException'
Summary: bridges:arm failure to start OOo - terminate called after throwing an instanc...
Status: CLOSED FIXED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: OOo 3.1.1
Hardware: Unknown Linux, all
: P2 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: rene
QA Contact: issues@udk
URL:
Keywords:
Depends on:
Blocks: 81913
  Show dependency tree
 
Reported: 2009-09-25 15:10 UTC by doko
Modified: 2010-05-26 16:13 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
the extra bit (3.68 KB, patch)
2010-05-04 15:26 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description doko 2009-09-25 15:10:56 UTC
arm failure to start OOo - terminate called after throwing an instance of
'com::sun::star::ucb::InteractiveAugmentedIOException'

Seen with the binutils-2.20 branch, the binutils report is

  http://sourceware.org/bugzilla/show_bug.cgi?id=10695

feedback from Paul Brook:

  I guess you get to debug it then.  Figure out what's wrong with
  the unwind tables, and where that bogosity comes from. My WAG
  would be that it works by chance before because it's picking up
  an unwind table from some other funciton.  After the patch we're
  inserting cantunwind markers for code that can't be unwound,
  so the latent failure is exposed.
Comment 1 kay.ramme 2009-09-28 08:54:04 UTC
How urgent is this? I am not sure I find the time to fix this this week, and the 
next two weeks I am on vacation ;-)
Comment 2 doko 2009-09-28 13:18:08 UTC
worked around that by linking this library with an older ld. Is this a latent
architecture indepent problem only showing up on arm-linux-gnueabi by chance?
Comment 3 rene 2009-09-28 14:58:54 UTC
> How urgent is this? I am not sure I find the time to fix this this week, and
> the  next two weeks I am on vacation ;-)

Counter-question. How is a OOo not starting up at all not urgent?
(ok, it so far was only seen on armel, but that is shipped by distros..)
Comment 4 rene 2009-09-28 15:09:30 UTC
I think the priority should be bumped...
Comment 5 kay.ramme 2009-09-28 17:12:19 UTC
My understanding is, that this is because of an external change, and there seems 
to be a workaround.

->Rene: AFAIK you aware that we don't have any arm here yet, so I do have to set 
up some emulation environment etc. first. This takes some time.
Comment 6 rene 2009-09-28 17:23:50 UTC
> My understanding is, that this is because of an external change, and there
> seems  to be a workaround.

The workaround is "build with older ld (read: binutils)". Which is not possible
as I have to take what is in Debian. And that is the broken binutils...
Until this issue either is fixed in binutils or OOo we have a broken build

> ->Rene: AFAIK you aware that we don't have any arm here yet, so I do have to
> set up some emulation environment etc. first. This takes some time.

I just answered your question :)
Comment 7 kay.ramme 2009-09-30 15:14:40 UTC
Do we have a stack trace? 
Comment 8 kay.ramme 2009-10-02 10:38:33 UTC
Added SB
Comment 9 kay.ramme 2009-10-02 15:27:48 UTC
... so, I am away for the next two weeks - anyone volunteering?
Comment 10 caolanm 2009-10-02 15:44:05 UTC
I might have a stab at it if I get a chance. There is one little quirk of a
difference between the arm eabi exception header vs all other linux platforms so
I might have gotten that bit wrong, though it did seem to work up until this
reported change in binutils.
Comment 11 doko 2009-10-02 15:50:49 UTC
yes, I'm currently building with -fno-dwarf2-cfi-asm (or build with gcc-4.4 from
the 4.4 branch); just building the shared library with this option isn't enough.
Comment 12 caolanm 2009-10-02 15:57:29 UTC
Maybe we need some magic unwind smoke in armhelper.s or something
Comment 13 doko 2009-10-08 16:21:35 UTC
amazingly not a problem with OOo. When using gcc-4.4, you'll have to use
binutils 2.20 and a gcc-4.4 version with the changes described in
http://gcc.gnu.org/PR40521
Comment 14 caolanm 2009-10-08 16:30:56 UTC
oky doky, sounds good.
Comment 15 doko 2009-10-21 13:02:31 UTC
reopening; apparently I made a mistake with testing. there's another binutils
related bug, now http://gcc.gnu.org/PR41684, but building the library with
-fno-section-anchors doesn't help either. so back to step 1 ...
Comment 16 doko 2009-10-21 13:04:31 UTC
and the workaround undoing the binutils unwinder changes doesn't help anymore.
so no workaround for now.
Comment 17 kay.ramme 2009-11-05 08:03:30 UTC
.
Comment 18 kay.ramme 2009-12-22 14:18:52 UTC
... while building I am stumbling over a minor issue in uno2cpp.cxx, __SOFTFP__ 
seems to absent nowadays. IMHO instead of checking for absence it is better to 
check for availability, that means, is there similar macro may be called 
__HARDFP__, or so?


Comment 19 doko 2009-12-23 08:59:33 UTC
> __SOFTFP__  seems to absent nowadays. IMHO instead of checking for
> absence it is better to check for availability,

it's defined if using -mfloat-abi=soft, not when using -mfloat-abi=softfp, but
both of these use the same abi.

> that means, is there similar macro may be called 
> __HARDFP__, or so?

No. unfortunately not. but there is no code there (yet) that is built with
-mfloat-abi=hard.
Comment 20 kay.ramme 2010-01-14 13:51:07 UTC
Currently stumbling over 

/home/ubuntu/work_DEV300/solver/300/unxlngr.pro/lib/libgraphite.a(Font.o): In
function `gr3ooo::Font::~Font()':
Font.cpp:(.text+0xbd8): undefined reference to `__sync_fetch_and_add_4'

etc. while linking VCL. Using system graphite does not work either.

Any quick tips?
Comment 21 caolanm 2010-01-14 13:57:47 UTC
--disable-graphite ?

Personally I'd "guess" this is just a tool-chain issue, not bustage in OOo, but
I can't prove it one way or the other.

cmc->doko: This problem is still live right in current Ubuntu ?
Comment 22 doko 2010-01-14 13:58:52 UTC
unsure why you do see this. which compiler is used? use of the atomic builtins
was fixed in the gcc-4.4 shipped with Ubuntu karmic, and is fixed in the
upstream gcc-4_4-branch (which will become 4.4.3). A quick workaround might be
to explicitely link graphite with -lgcc_s -lgcc.
Comment 23 caolanm 2010-01-14 13:59:13 UTC
oh yeah, that reminds me, current DEV300 runs testtools cppu tests during the
build now, so that should work as a smoke test to flush out bridge errors.
Comment 24 doko 2010-01-14 14:24:00 UTC
still seen with an 3.1.1 rebuild on lucid (current development release)
Comment 25 kay.ramme 2010-01-19 07:42:06 UTC
For whatever reason disabling graphite did not work, also graphite becomes build
as an archive / static lib. Just linked vcl against gcc_s / gcc as a workaround.

Build continues.
Comment 26 mcasadevall 2010-02-17 11:19:26 UTC
Still seen with 3.2.0 RC. Did some more digging, testtools successfully passes 
all pyuno test but causes Python to abort. This suggests to me that something is 
breaking the stack on ARM in UNO although its not clear where this may be; I've 
yet to get a decent GDB backtrace of the crash.

root@arm:~/src/ooo/openoffice.org-3.2.0~rc4/ooo-
build/build/OOO320_m11/testtools/source/bridgetest/pyuno# dmake runtest
start test with  dmake runtest
------------- 
cd ../../../unxlngr.pro/lib && export 
FOO=file:///home/nc/src/ooo/openoffice.org-3.2.0~rc4/ooo-
build/build/OOO320_m11/testtools/source/bridgetest/pyuno/../../../unxlngr.pro/li
b     UNO_TYPES=pyuno_regcomp.rdb UNO_SERVICES=pyuno_regcomp.rdb && python 
main.py
testStandard (importer.ImporterTestCase) ... ok
testDynamicComponentRegistration (importer.ImporterTestCase) ... ok
testErrors (core.TestCase) ... ok
testBaseTypes (core.TestCase) ... ok
testOutparam (core.TestCase) ... ok
testStruct (core.TestCase) ... ok
testType (core.TestCase) ... ok
testEnum (core.TestCase) ... ok
testBool (core.TestCase) ... ok
testChar (core.TestCase) ... ok
testUnicode (core.TestCase) ... ok
testConstant (core.TestCase) ... ok
testExceptions (core.TestCase) ... ok
testInterface (core.TestCase) ... ok
testByteSequence (core.TestCase) ... ok
testInvoke (core.TestCase) ... ok
testStandard (impl.TestCase) ... ok
testUrlHelper (impl.TestHelperCase) ... ok
testInspect (impl.TestHelperCase) ... ok
testListener (impl.TestHelperCase) ... ok
testCurrentContext (impl.TestHelperCase) ... ok

----------------------------------------------------------------------
Ran 21 tests in 0.571s

OK
Fatal Python error: PyImport_GetModuleDict: no module dictionary!
/bin/bash: line 1: 29354 Aborted                 (core dumped) python main.py
dmake:  Error code 134, while making 'runtest'

When using the jaunty version (OOo 3.0) which allows OOo to run, the output is 
the following:
root@arm:~/src/ooo/openoffice.org-3.2.0~rc4/ooo-
build/build/OOO320_m11/testtools/source/bridgetest/pyuno# dmake runtest
start test with  dmake runtest
------------- 
cd ../../../unxlngr.pro/lib && export 
FOO=file:///home/nc/src/ooo/openoffice.org-3.2.0~rc4/ooo-
build/build/OOO320_m11/testtools/source/bridgetest/pyuno/../../../unxlngr.pro/li
b     UNO_TYPES=pyuno_regcomp.rdb UNO_SERVICES=pyuno_regcomp.rdb && python 
main.py
testStandard (importer.ImporterTestCase) ... ok
testDynamicComponentRegistration (importer.ImporterTestCase) ... ok
testErrors (core.TestCase) ... ok
testBaseTypes (core.TestCase) ... ok
testOutparam (core.TestCase) ... ok
testStruct (core.TestCase) ... ok
testType (core.TestCase) ... ok
testEnum (core.TestCase) ... ok
testBool (core.TestCase) ... ok
testChar (core.TestCase) ... ok
testUnicode (core.TestCase) ... ok
testConstant (core.TestCase) ... ok
testExceptions (core.TestCase) ... ok
testInterface (core.TestCase) ... ok
testByteSequence (core.TestCase) ... ok
testInvoke (core.TestCase) ... ok
testStandard (impl.TestCase) ... ok
testUrlHelper (impl.TestHelperCase) ... ok
testInspect (impl.TestHelperCase) ... ok
testListener (impl.TestHelperCase) ... ok
testCurrentContext (impl.TestHelperCase) ... ok

----------------------------------------------------------------------
Ran 21 tests in 0.577s

OK
cd ../../../unxlngr.pro/lib && export 
FOO=file:///home/nc/src/ooo/openoffice.org-3.2.0~rc4/ooo-
build/build/OOO320_m11/testtools/source/bridgetest/pyuno/../../../unxlngr.pro/li
b     UNO_TYPES=pyuno_regcomp.rdb UNO_SERVICES=pyuno_regcomp.rdb &&  : &&     
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/nc/src/ooo/openoffic
e.org-3.2.0~rc4/ooo-build/build/OOO320_m11/solver/320/unxlngr.pro/lib 
/home/nc/src/ooo/openoffice.org-3.2.0~rc4/ooo-
build/build/OOO320_m11/solver/320/unxlngr.pro/bin/regcomp -register -br 
pyuno_regcomp.rdb -r dummy.rdb \
			-l com.sun.star.loader.Python -c 
vnd.openoffice.pymodule:samplecomponent
vnd.openoffice.pymodule:samplecomponent
register component 'vnd.openoffice.pymodule:samplecomponent' in registry 
'dummy.rdb' failed!
error (RuntimeException): python-loader:<type 'exceptions.ImportError'>: No 
module named pythonloader, traceback follows
no traceback available
dmake:  Error code 1, while making 'runtest'

I'm going to move to working against OOo upstream versus Ubuntu source packages, 
but I've gotten reports that Debian's OOo is affected on ARM when built with GCC 
4.4.
Comment 27 rene 2010-02-17 12:10:41 UTC
mcasadevall: and even with gcc 4.3
Comment 28 doko 2010-03-11 10:03:25 UTC
see for further comments:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009
Comment 30 rene 2010-03-15 13:03:06 UTC
11:58 < lool> _rene_: bad news, fix for ARM stuff is actually wrong; a stack 
              entry is actually needed; but I guess now that the problem is 
              understood, a new fix should come up relatively quickly
11:58 < lool> _rene_: I think it's mostly a matter of .fnstart and .fnend macro
Comment 31 rene 2010-03-19 09:10:57 UTC
ok, they came up with a new patch:

https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009/comments/73

My testbuild with it just finished and OOo starts! So I can confirm that patch
fixes it... (as did Mandriva already as far as I hear)
Comment 32 rene 2010-03-19 16:20:11 UTC
but I fear the change broke extensions:

Enabling: Presentation Minimizer
 Enabling: SunPresentationMinimizer.xcs
 Enabling: SunPresentationMinimizer.uno.so

ERROR: (com.sun.star.deployment.DeploymentException) { { Message = "An error
occurred while enabling: SunPresentationMinimizer.uno.so", Context =
(com.sun.star.uno.XInterface) @111730 }, Cause = (any) {
(com.sun.star.registry.CannotRegisterImplementationException) { { Message =
"ImplementationRegistration::registerImplementation() InvalidRegistryException
during registration (destination registry is read-only!  cannot merge!)",
Context = (com.sun.star.uno.XInterface) @0 } } } }
 rollback...
  Disabling: SunPresentationMinimizer.xcs
  rollback finished.
An error occurred while enabling: SunPresentationMinimizer.uno.so

arch-indep extensions (e.g. wiki publisher) seem to work, so it can't be word
for word what it says...
Comment 33 caolanm 2010-04-27 11:23:13 UTC
Taking this. I can now reproduce the original problem now that we've got the
testtools tests in place in 3.3.0 and I can also see extra problems about struct
returning rules which *might* be what's triggering rene's other problem.
Comment 34 caolanm 2010-04-27 11:25:09 UTC
You can give http://hg.services.openoffice.org/cws/armeabi02/rev/36887d11c60f a
go for the combined fixes to date for the exception stuff that NCommander fixed
up + the missing small struct return in registers stuff.
Comment 35 rene 2010-04-29 08:59:13 UTC
hmm, the extension problem persists here..
Comment 36 caolanm 2010-04-29 11:10:30 UTC
I'll have a look at that as well, when my build gets there, though there's no
reason to be sure that it makes the current proposed changes incorrect :-)
Comment 37 caolanm 2010-05-04 14:35:18 UTC
reproduced it, fixed it, can't push it due to hg outage, to-do, remember to push
Comment 38 rene 2010-05-04 15:16:46 UTC
caolan: you mean you also fixed the extension problem now? can you add the diff
by chance as long as hg is down?
Comment 39 caolanm 2010-05-04 15:26:20 UTC
Created attachment 69286 [details]
the extra bit
Comment 40 caolanm 2010-05-06 14:42:50 UTC
build works for me, extensions register too.

cmc->rene: can you verify that this works for your builds too.
Comment 41 rene 2010-05-06 14:54:44 UTC
yes, build just finished. works for me.
Comment 42 caolanm 2010-05-26 16:13:51 UTC
closing, integrated DEV300_m79