Ticket #1691 (in_testing defect)

Opened 6 years ago

Last modified 6 years ago

[Qtopia] qpe crash happened after flash the new image

Reported by: wendy_hung Owned by: tick
Priority: highest Milestone: Om2008.10
Component: Qtopia Version:
Severity: blocker Keywords:
Cc: testing@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

kernel:20080723-asu.stable-uImage.bin
root file system:20080730-asu.stable-rootfs.jffs2

Summary:
qpe crash happened after flash the new image

Step + current result:
1) flash the new image
2) launch the device
3) the qpe crash error message pop up
4) error message :

-Application Error-

The qpe process Vanished. This is bad. This is not meant to happen and is likely a sign of a bug in Qtopia. Please try to reproduce it and report the issue to http://docs.openmoko.org.
To be able to use your phone as a phone again you will have to restart Qtopia.

[(F1)Restart] [(F2)Exit]

Attachments

logg.txt (14.6 KB) - added by Toscho 6 years ago.
/var/log/messages nachdem /etc/X11/Xsession.d/89qtopia nach zecks vorschlägen angepasst wurde

Change History

comment:1 Changed 6 years ago by wendy_hung

The hole process for me works like this:
flash the new image ---> power on the device ---> wait wait wait ---> the device with the home screen ---> suspend time come (system default setting) ---> resume ---> show up the error message

comment:2 Changed 6 years ago by wendy_hung

Tested with the image below:

kernel:20080807-asu.stable-uImage.bin
root file system:20080807-asu.stable-rootfs.jffs2

On device NO.68, I flashed twice but all of them have the qpe crash and even I Restart it still comes out all the time. Not the case in other device.

comment:3 Changed 6 years ago by regina_kim

  • Milestone changed from Om2008.8 to Om2008.9

comment:4 Changed 6 years ago by zecke

Get a dev to do the following on your device:

vi /etc/X11/Xsession.d/89qtopia

before launching qpe add a "ulimit -c 99999999", restart the device if qpe crashes provide me with the coredump (probably don't attach it to the bug report).

Changed 6 years ago by Toscho

/var/log/messages nachdem /etc/X11/Xsession.d/89qtopia nach zecks vorschlägen angepasst wurde

comment:5 Changed 6 years ago by Toscho

Got the same problem. The device starts, one gets to see the homescreen, there is short blackscreen (like an eyeblink), one gets to see the homescreen again and after a while the qpe-message pops up. Clicking on "F1: Restart" doesn't help, of course.

This bug first occured after changing /etc/fstab so that /dev/mmcblk0p2 is mounted as /media/card but still occurs after changing /etc/fstab so that /dev/mmcblk0p1 is mounted as /media/card and /dev/mmcblk0p2 is mounted as /media/cardzwei.

comment:6 Changed 6 years ago by zecke

I don't see a coredump attached.

comment:7 Changed 6 years ago by Toscho

If you tell me, where to get the coredump, I'll attach it.

comment:8 Changed 6 years ago by zecke

Hmmm... It could be in / or /home/root... find / -name '*core*' should find it.

comment:9 Changed 6 years ago by Toscho

http://www.tobias-schoel.de/core diese Datei ist eine Kopie von /core nach der qpe-Nachricht.

comment:10 Changed 6 years ago by Toscho

Bug is reproducible:

  1. Flash Neo with FDOM-Distribution as of 2008-09-13
  2. opkg update
  3. opkg install nano (probably totally irrelevant)
  4. opkg upgrade
  5. reboot

So it seems, as if the upgrade is broken.

comment:11 Changed 6 years ago by will

  • Milestone changed from Om2008.9 to Om2008.10

comment:12 Changed 6 years ago by csamuel

I was seeing the same issue on my FreeRunner? with FDOM 2008-09-13 as Toscho described (without the nano step). Digging in the logs it appeared that qpe was having problems talking to the modem and logging lots of timeouts, after a number of which QPE would exit and the watcher would pop up the window.

I found that restarting the GSM daemon would fix the timeout problem (or at least it would be able to talk to the modem successfully and stopped crashing), but the phone still wouldn't register with the network (unlike under the standard FDOM 20080913 release).

I'm upgrading to the OM 2008.9 release (pending the FDOM version) to see whether that's working now.

comment:13 Changed 6 years ago by Toscho

Somewhere on the mailing lists i found this workaround:

chmod a+rx /etc/X11/Xsession.d/89qtopia

but that didn't work, which means, after a reboot, the qpe-message again popped up. I then tried chmod +rx /etx/X11/Xsession.d/89qtopia and it worked although I don't understand why then.

comment:14 Changed 6 years ago by csamuel

OM 2008.9 flashes OK and works, which is positive.

What I don't see is the /var/log/messages file I was seeing with FDOM, I presume that's an FDOM enhancement ?

comment:15 Changed 6 years ago by tick

  • Status changed from new to accepted
  • Owner changed from zecke to tick

Hi Csamuel,
"logread" may help

Is this bug still happen to you?

Cheers,
Tick

comment:16 Changed 6 years ago by zecke

@tick: What about taking a look at the coredump first?

comment:17 Changed 6 years ago by zecke

Okay, I just tried to get a backtrace from the coredump with my compiled version of Qtopia and did not get anywhere. This means we need a way to reproduce this. E.g. is this with SD card in or not?

comment:18 Changed 6 years ago by goldie

qtopia-phone-x11 - 1:4.3.2+gitr429+563d5f4c781efe1a11680c6a055b409034b528ab-r41 - 
kernel - 3:2.6.24+gitr75969+a1e97c611253511ffc2d8c45e3e6d6894fa03fa3-r2 - 
FDOM, testing branch

Removed the SD card, nothing changed for me.
I also attached gdb to the qpe process:

root@om-gta02:~# gdb --pid=1380
GNU gdb 6.8
(...)
This GDB was configured as "arm-angstrom-linux-gnueabi".
Attaching to process 1380

Reading symbols (...)

(gdb) continue
Continuing.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x41aa6570 (LWP 1380)]
0x41874df4 in raise () from /lib/libc.so.6
(gdb) backtrace
#0  0x41874df4 in raise () from /lib/libc.so.6
#1  0x418763fc in abort () from /lib/libc.so.6
Backtrace stopped: frame did not save the PC

Messages in /var/log/messages are the same.

comment:19 Changed 6 years ago by john_lee

  • Status changed from accepted to in_testing
  • HasPatchForReview unset

The current image in testing repo should not have this problem. Please verify.

Note: See TracTickets for help on using tickets.