[Solved] {Re: Segmentation fault during rpm upgrade/re-install

[gaurav salia]

Thanks for the replies, Greg and Panu. And sorry for the delay in replying,
I was travelling.

Greg: I had already looked at the pre and post install/uninstall scripts,
there was nothing interesting there.

Panu: strace didn't give much info either and gbd complained that the
backtrace was corrupted. I increased the size of the VM and was finally
able to get a backtrace with some info.

It turned out that the rpm bundle was replaced libz.so with a version that
the "rpm" command didn't like. So the first install would work, but any rpm
command after that failed because libz.so version was not what "rpm"
expected. Not replacing the existing libz.so and setting LD_LIBRARY_PATH
for the program being installed to use the required version from a
different location fixed the issue.

Thanks for all the help!

Gaurav

On Wed, Oct 3, 2012 at 11:39 PM, Panu Matilainen
<pmatilai at laiskiainen.org>wrote:

> On 10/03/2012 01:44 AM, gaurav salia wrote:
>
>> Hello,
>>
>> I looked through the archives till Jan 2011 but could not find a thread
>> similar to this issue, so I hope this is not a repost.
>>
>> System configuration: I am running 32-bit RHEL 6 basic server
>> with rpm-4.8.0-27.el6.i686
>> Rpm package: Let's call it myApp.rpm
>>
>> Before I go into the details, I am able to install/upgrade/erase myApp.rpm
>> on RHEL 5 without any problems. This has been working for more than a
>> year.
>> I had to move to RHEL 6 because myApp now requires a glibc version which
>> is
>> newer than the one on RHEL 5.
>>
>> The Problem: After I install myApp.rpm and start the application, I am not
>> able to upgrade or re-install myApp.rpm. I have been using -vv option and
>> the output looks like:
>> Success case: Fresh install
>> D:         60 /usr/libexec/hostd/
>> D:         61 /usr/sbin/
>> D:         62 /vmfs/devices/char/vmkdriver/
>> D:         63 /vmfs/volumes/sdrsLoadDef/
>> D: ==========
>> D: fini      120777  1 (   0,   0)        15 /bin/python;506a01b8
>> D: fini      100555  1 (   0,   0)   1093280 /bin/rhttpproxy;506a01b8
>> D: fini      100500  1 (   0,   0)      4891
>> /etc/init.d/mgmt-vmware;506a01
>>
>> Failure case: Upgrade/re-install after running the application
>> D:         60 /usr/libexec/hostd/
>> D:         61 /usr/sbin/
>> D:         62 /vmfs/devices/char/vmkdriver/
>> D:         63 /vmfs/volumes/sdrsLoadDef/
>> D: ==========
>> Segmentation fault (core dumped)    <-----------------------------**-----
>> Failure
>>
>> I tried a lot of different scenarios and below is the list of what works:
>> 1. Fresh install works fine - rpm -ivvf
>> 2. Delete works fine - rpm -evv
>> 3. Re-insall after deleting rpm in step (2) works fine as long as myApp
>> was
>> not started after installation: rpm -ivvf
>> 4. Upgrade after step (1) works fine  as long as myApp was not started
>> after installation: rpm -Uvvf
>>
>> Scenarios that don't work:
>> 5. Upgrade after step (1) after starting myApp: rpm -Uvvf
>> 6. Re-insall after deleting rpm in step (2) after starting myApp: rpm
>> -ivvf
>> 7. I see the crash even if stop myApp and then do upgrade/re-install
>>
>> So basically after the app is started, I can only do erase. Upgrade or
>> re-install fails with Seg fault. The crash is after rpm has done
>> processing
>> ''Directories not explicitly included in package:'' I can upload the
>> complete output of -vv for success(install, upgrade, erase) and
>> failure(upgrade, re-install).
>>
>> Any help about how to find the root cause of the crash would be highly
>> appreciated!
>>
>
> Rpm segfaulting typically means a bug in rpm... and if it worked in RHEL 5
> and crashes in 6, its a regression.
>
> Since you're apparently a RHEL customer, you should report this through
> the official support channels (note that bugzilla is NOT an official
> support channel, although an additional bugzilla report wont hurt either)
> to get it fixed.
>
>
> > D:         62 /vmfs/devices/char/vmkdriver/
> > D:         63 /vmfs/volumes/sdrsLoadDef/
>
> This smells like some kind of virtual filesystem (Vmware?), which probably
> has some special characteristics when accessed, and would be my primary
> initial suspect for the cause of the crash. A strace of the failure case
> might provide the necessary clues, gdb backtrace for added bonus. The -vv
> output of rpm might be helpful too.
>
>         - Panu -
>
> ______________________________**_________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/**listinfo/rpm-list<http://lists.rpm.org/mailman/listinfo/rpm-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20121018/979a53a7/attachment.html>