Notices
Page 29 of 31 « First 192728 29 3031
Reply
Thread Tools
handaxe is offline handaxe
2013-04-18 , 12:40
Posts: 1,378 | Thanked: 1,604 times | Joined on Jun 2010 @ Göteborg, Sweden
#281
Originally Posted by avidscavenger View Post
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....
Last edited by handaxe; 2013-04-18 at 12:47.
 

The Following 3 Users Say Thank You to handaxe For This Useful Post:
avidscavenger is offline avidscavenger
2013-04-18 , 13:43
Posts: 96 | Thanked: 80 times | Joined on May 2010
#282
Originally Posted by handaxe View Post
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.

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.

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.
 

The Following 2 Users Say Thank You to avidscavenger For This Useful Post:
Estel's Avatar
Estel is offline Estel
2013-04-19 , 00:05
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#283
Originally Posted by avidscavenger View Post
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
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 2 Users Say Thank You to Estel For This Useful Post:
avidscavenger is offline avidscavenger
2013-04-19 , 00:10
Posts: 96 | Thanked: 80 times | Joined on May 2010
#284
Originally Posted by Estel View Post
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
 

The Following 3 Users Say Thank You to avidscavenger For This Useful Post:
avidscavenger is offline avidscavenger
2013-04-19 , 01:07
Posts: 96 | Thanked: 80 times | Joined on May 2010
#285
Originally Posted by handaxe View Post
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?
 

The Following 4 Users Say Thank You to avidscavenger For This Useful Post:
handaxe is offline handaxe
2013-04-20 , 01:10
Posts: 1,378 | Thanked: 1,604 times | Joined on Jun 2010 @ Göteborg, Sweden
#286
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....
 

The Following User Says Thank You to handaxe For This Useful Post:
avidscavenger is offline avidscavenger
2013-04-20 , 01:26
Posts: 96 | Thanked: 80 times | Joined on May 2010
#287
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:

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.
 

The Following 2 Users Say Thank You to avidscavenger For This Useful Post:
handaxe is offline handaxe
2013-04-20 , 01:49
Posts: 1,378 | Thanked: 1,604 times | Joined on Jun 2010 @ Göteborg, Sweden
#288
Originally Posted by avidscavenger View Post
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?
Last edited by handaxe; 2013-04-20 at 15:21.
 

The Following User Says Thank You to handaxe For This Useful Post:
avidscavenger is offline avidscavenger
2013-04-20 , 11:47
Posts: 96 | Thanked: 80 times | Joined on May 2010
#289
What are the implications of a lower level compilation?
More intensive CPU usage and/or a larger executable.

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
 

The Following 3 Users Say Thank You to avidscavenger For This Useful Post:
freemangordon is offline freemangordon
2013-04-20 , 12:33
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#290
@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
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer
 

The Following 5 Users Say Thank You to freemangordon For This Useful Post:
Reply
Page 29 of 31 « First 192728 29 3031

Tags
navigation, nokia n900

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 16:40.

Contact Us - Home - Archive - Top