Bug 431396 - Consistently dumps core when opening a database
Consistently dumps core when opening a database
Product: Fedora
Classification: Fedora
Component: compat-db (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Jindrich Novy
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-04 00:52 EST by Eric Hopper
Modified: 2013-07-02 19:26 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-22 17:47:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eric Hopper 2008-02-04 00:52:05 EST
Description of problem:
Anything that uses /lib64/libdb-4.5.so consistently segfaults when opening the
database.  This is mostly affecting me because of postgrey.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. cd /var/spool/postfix/postgrey
2. /usr/bin/db45_dump postgrey.db
Actual results:
A segmentation fault (with a core dump if you have things set properly)

Expected results:
A dump of the database

Additional info:
# gdb db45_dump
GNU gdb Red Hat Linux (6.6-40.fc8rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run postgrey.db
Starting program: /usr/bin/db45_dump postgrey.db

warning: Missing the separate debug info file:
(no debugging symbols found)
(no debugging symbols found)

warning: Missing the separate debug info file:
[Thread debugging using libthread_db enabled]

warning: Missing the separate debug info file:
[New Thread 46912499486688 (LWP 3775)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912499486688 (LWP 3775)]
__db_des_get (dbenv=0x603010, env_infop=0x0, infop=0x603960, rpp=0x7fff08514c78)
    at ../../env/env_region.c:1053
1053                    if (rp->id == INVALID_REGION_ID) {
(gdb) bt
#0  __db_des_get (dbenv=0x603010, env_infop=0x0, infop=0x603960, 
    rpp=0x7fff08514c78) at ../../env/env_region.c:1053
#1  0x00002aaaaab7c0e4 in __db_e_attach (dbenv=0x603010, 
    init_flagsp=0x7fff08514d24) at ../../env/env_region.c:264
#2  0x00002aaaaab78e8e in __env_open (dbenv=0x603010, 
    db_home=<value optimized out>, flags=4096, mode=<value optimized out>)
    at ../../env/env_open.c:281
#3  0x0000000000400d94 in ?? ()
#4  0x00000000004017d2 in ?? ()
#5  0x000000353461e074 in __libc_start_main () from /lib64/libc.so.6
#6  0x0000000000400c99 in ?? ()
#7  0x00007fff08514f08 in ?? ()
#8  0x0000000000000000 in ?? ()
(gdb) list
1048             */
1049            maxid = REGION_ID_ENV;
1050            empty_slot = first_type = NULL;
1051            for (rp = R_ADDR(env_infop, renv->region_off),
1052                i = 0; i < renv->region_cnt; ++i, ++rp) {
1053                    if (rp->id == INVALID_REGION_ID) {
1054                            if (empty_slot == NULL)
1055                                    empty_slot = rp;
1056                            continue;
1057                    }
Comment 1 Eric Hopper 2008-02-04 09:50:39 EST
Both env_infop and renv are NULL.  rp isn't though, which is a curious thing,
you would expect the coredump to be on line 1051.  I suspect optimizer
shenanigans.  Not that it's done anything wrong, just that it's making the cause
more obscure.
Comment 2 Jindrich Novy 2008-02-14 00:39:15 EST
Thanks for the report. I'm not postgrey user, so to reproduce it I would need
you to attach the postgrey.db here or write me a minimalistic example on how to
create one myself, where this bug is reproducible. After that I can inspect it
and fix it.
Comment 3 Christopher D. Stover 2008-10-22 17:47:32 EDT
The information we've requested above is required in order
to review this problem report further and diagnose or fix the
issue if it is still present.  Since it has been thirty days or
more since we first requested additional information, we're assuming
the problem is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "CLOSED: INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.

Thank you in advance.

Note You need to log in before you can comment on or make changes to this bug.