maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Applications (https://talk.maemo.org/forumdisplay.php?f=41)
-   -   [ANNOUNCE] Columbus Navigation Toolkit (https://talk.maemo.org/showthread.php?t=67276)

handaxe 2013-04-18 12:40

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Quote:

Originally Posted by avidscavenger (Post 1336889)
Great - can you tell me how or give me a reference on setting up core dumps?

[UPDATE]My phone is unbricked. :) The problem was somehow caused by columbus - its install scripts removed some library directories from /etc/ld.so.conf which mean that core apps (modest) wouldn't load which sent the phone into a reboot loop.

Given your experience and that columbus never did that to me, I think I will pass on your debug builds, no offence :-) Anyhow, I am pressed for space and installing all of gdb, dev libs is unattractive.

BUT, I have 2 core-dumps from columbus under different usages, one streaming one not. So lets see if this helps at all. Details of file access sent via PM.

Setting up core dumps is simple:

(as user)
Code:

mkdir ~/MyDocs/core-dumps
(as root) add the following repos to /etc/apt/sources.list

Code:

deb http://repository.maemo.org/ fremantle/sdk free non-free
deb http://repository.maemo.org/ fremantle/tools free non-free

then
Code:

apt-get update && apt-get install sp-rich-core
And then you wait for misbehaviour..... whereupon core-dumps folder will offer what ye seek.

PS: remember that the dumps will accummulate as programs misbehave, and if you forget that, you may be surprised by diminishing storage over time. Bit like enabling syslog....

avidscavenger 2013-04-18 13:43

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Quote:

Originally Posted by handaxe (Post 1336990)
Given your experience and that columbus never did that to me, I think I will pass on your debug builds, no offence :-) Anyhow, I am pressed for space and installing all of gdb, dev libs is unattractive.

Although I can understand your misgivings I'm quite certain the problems are totally unrelated. All I did to build a debug version was change a single build option so that compilation and linking is done with a debug flag and without optimisation. The problem with bricking was, by the only explanation I can come up with, caused by a postinstall script.

Quote:

BUT, I have 2 core-dumps from columbus under different usages, one streaming one not. So lets see if this helps at all. Details of file access sent via PM.
I will take a look at them in the morning. It's late evening my time.

Quote:

Setting up core dumps is simple:
Thank you for that info. I saw some references to sp-rich-core but wasn't sure in which repository it could be found. I'll check it out too.

Estel 2013-04-19 00:05

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Quote:

Originally Posted by avidscavenger (Post 1337001)
The problem with bricking was, by the only explanation I can come up with, caused by a postinstall script.

More details on that, please? What it exactly deletes, and why the hell would it do it? I have Columbus installed, and my modest works OK, not to mention no bootloops.

If postinst script is really fubar, it would require immediate fixing and uploading new version to -devel.

/Estel

avidscavenger 2013-04-19 00:10

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Quote:

Originally Posted by Estel (Post 1337179)
If postinst script is really fubar, it would require immediate fixing and uploading new version to -devel.

Agreed! I've checked out the scripts and they look fine to me. All I know is I was messing around with building, installing, uninstalling various versions of columbus. At some point modest started returning an error. Naively I thought that rebooting would help - in fact it did the opposite and I had to learn a bit more about bootloader options before I could get it back on track.

My best explanation at this point is that I may have interrupted an install or uninstall process at an inopportune moment. In any case I'm still messing about with columbus so I'll be extra careful to check if it happens again.

Jonathan

avidscavenger 2013-04-19 01:07

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Quote:

Originally Posted by handaxe (Post 1336990)
BUT, I have 2 core-dumps from columbus under different usages, one streaming one not. So lets see if this helps at all.

They don't give me much extra information, but there is one good piece of news which is the segfault seems to be the same in each case, which is also the same as what I found running gdb on a non-debug build, which is a crash in QString::fromLatin1_helper

One thing I notices is that you have more versions of a few libraries compared with me. I thought my apt sources were up to date but apparently this is not the case. Can you show me what you have?

handaxe 2013-04-20 01:10

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
2 more crash logs if you want them on my site.

Here is my sources.list (well actually "hildon-application-manager-list" given how maemo works):

I can try for a gdb log if you want; let me know....

avidscavenger 2013-04-20 01:26

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Ah OK I see I was missing the community-testing repo.

I don't think I need any more core dumps, since they all look pretty much the same:

Quote:

Program terminated with signal 11, Segmentation fault.
#0 0x40e7d098 in QString::fromLatin1_helper(char const*, int) () from /usr/lib/libQtCore.so.4
0x40e7d098 <_ZN7QString17fromLatin1_helperEPKci+76>: ldrb r3, [r8]
(gdb) bt
#0 0x40e7d098 in QString::fromLatin1_helper(char const*, int) () from /usr/lib/libQtCore.so.4
#1 0x40e8710c in QString::fromAscii_helper(char const*, int) () from /usr/lib/libQtCore.so.4
#2 0x00015c24 in ?? ()
#3 0x00015c24 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I don't really know enough about arm architecture to say with any certainty whether this really is likely to be a corrupt stack, a bug in gdb or something else.

What I do notice however is that if columbus is compiled with optimisation level 2 or higher then it crashes while with level 1 or lower it seems to be OK. Possibly the code does something weird that doesn't work when the compiler tries to optimise it?

But this does suggest an ugly work-around... just build it with a lower level of compiler optimisation.

handaxe 2013-04-20 01:49

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Quote:

Originally Posted by avidscavenger (Post 1337464)
Ah OK I see I was missing the community-testing repo.

OK, make sure you get the CSSU-testing installed as you can read here:
http://wiki.maemo.org/Community_SSU

What are the implications of a lower level compilation?

Would a gdb trace with dbg versions of libraries (incl. QT) and the binary not provide more detail?

avidscavenger 2013-04-20 11:47

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
Quote:

What are the implications of a lower level compilation?
More intensive CPU usage and/or a larger executable.

Quote:

Would a gdb trace with dev versions of libraries (incl. QT) and the binary not provide more detail?
I think that gdb already has the symbols from the qt libraries.

The issue seems to be that the stack is either corrupted or gdb thinks that it is rather than we can't see where the process finally dies.

I also tried valgrind which gave a bit of extra information but not enough that I can see where the problem is:

Code:

==1875== Invalid read of size 1
==1875==    at 0x5697098: QString::fromLatin1_helper(char const*, int) (in /usr/lib/libQtCore.so.4.7.4)
==1875==  Address 0x73 is not stack'd, malloc'd or (recently) free'd


freemangordon 2013-04-20 12:33

Re: [ANNOUNCE] Columbus Navigation Toolkit
 
@avidscavenger - install qt -dbg packages and get some useful backtrace :).

Keep in mind that before install them you should move /usr/lib/debug to /opt or sdcard and symlink back, otherwise your rootfs will become full, qt debug symbols are about 200 MB or so


All times are GMT. The time now is 12:08.

vBulletin® Version 3.8.8