| Summary: | Do smart install and remove more times will occur Segmentation fault | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Runtime] Package Management Issues | Reporter: | Ning Zhang <ning.zhang> | ||||||
| Component: | RPM | Assignee: | Mark Hatle <mark.hatle> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | Yi Zhao <yi.zhao> | ||||||
| Severity: | normal | ||||||||
| Priority: | Medium | CC: | alexandru.c.georgescu, bluelightning, ke.zou, n3npq, sgw, yi.zhao | ||||||
| Version: | 1.5 | ||||||||
| Target Milestone: | 1.9 | ||||||||
| Hardware: | Beagleboard | ||||||||
| OS: | arm | ||||||||
| Whiteboard: | |||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||
| Verified: | Documentation change: | Don't know | |||||||
| Attachments: |
|
||||||||
|
Description
Ning Zhang
2013-07-19 08:53:45 UTC
Created attachment 1338 [details]
test log
I've done this test with below scenarios: 1. test 20130731-1 images, kernel is 3.4.52, poky is 9de0ad47462c13ac4a2d73e12e92be6c1b4e0415, test failed. 2. test 20130618-2 images, kernel is 3.4.36, poky is 590010a6525b0e1bc1de73e794764e23404591df, test pass. 3. Use scenario 1 image, downgrade kernel version with scenario 2(cp uImage, MLO files and /lib/modules/ files), which means use 3.4.36 kernel and 3.4.52 rootfs, test pass. 4. Use scenario 2 image, upgrade kernel version with scenario 1(cp uImage, MLO files and /lib/modules/ files), which means use 3.4.52 kernel and 3.4.36 rootfs, test failed. I tested all above on a same beagleboard xm target. So we guess this is not a hardware issue, it is the 3.4.52 kernel issue. A few notes. I have seen this behavior in the past, and it's always been tied to something within BerkleyDB. Unfortunately, I have no previously been able to reproduce it consistently enough to try to figure out what the cause actually is. My guess is that it's related to a mismatch in the locking between the host system and target on the initial creation of the database. In the past reconstructing the RPM DB (--rebuilddb) and/or simply removing the __db.* files has fixed the issue. If we can find someone with more in-depth knowledge of BerkleyDB then we might be able to find and fix the bug. Does this problem still exist? Can you try running under valgrind (moderately slow) or compiled with -fsanitize:address using gcc-4.8.2 and/or clang? I'd like to see a stack trace before hazarding a guess. There are also several issues fixed since Sept 2013 which might have been the cause. I will try to add some instrumentation to the system and see if we can reproduce the issue(s). (In reply to comment #5) > I will try to add some instrumentation to the system and see if we can > reproduce the issue(s). Adding Yi to the thread. Yi, does this happen in Beaglebone in 1.8? I've been unable to replicate this with YP 1.7 and YP 1.8 on an IA32 (32-bit or 64-bit) target system. I'm going to resolve this as I suspect the issue was fixed int he 1.7 time frame as part of the BerkleyDB and other standard upgrades. If the issue comes back, please reopen. We also didn't encounter this issue a long time. Mark it to verified. |