Subject: Segfault in several display modules on x86_64
Platform: GNU/Linux/x86_64
grass binary for platform: Compiled from Sources
GRASS Version: GRASS 6.1.cvs (2006) checkout 4/22/06
Segfault in several display modules (d.vect, d.zoom) on x86_64, Suse 9.2.
uname -a:
Linux node0 2.6.5-7.244_lustre.1.4.6smp #1 SMP Sat Feb 18 17:33:39 EST 2006 x86_64 x86_64 x86_64 GNU/Linux
For both d.vect and d.zoom SIGSEGV can be traced to G_whoami () at whoami.c:64. Here is GDB stack trace:
(gdb) where #0 0x0000002a96a33915 in strcpy () from /lib64/tls/libc.so.6 #1 0x0000002a95ef7ecc in set_string (x=0x50c4bc, s=0x2a95dec773 "0", copy=1)
at string.c:108 #2 0x0000002a95deb05b in db_version (driver=0x50c4b8,
client_version=0x50c4bc, driver_version=0x50c4c0) at c_version.c:20 #3 0x0000002a97be6a01 in __db_e_attach () from /usr/lib64/tls/libdb-4.2.so #4 0x0000002a97be4759 in __dbenv_open () from /usr/lib64/tls/libdb-4.2.so #5 0x0000002a97bc146e in __db_dbenv_setup () from /usr/lib64/tls/libdb-4.2.so #6 0x0000002a97bd5e6a in __db_open () from /usr/lib64/tls/libdb-4.2.so #7 0x0000002a97bd0c4d in __db_open_pp () from /usr/lib64/tls/libdb-4.2.so #8 0x0000002a97b707ea in __db185_open () from /usr/lib64/tls/libdb-4.2.so #9 0x0000002a977fcf5d in _nss_hash_open () from /lib64/libnss_ldap.so.2 #10 0x0000002a977fd0b5 in _nss_ldap_init_config () from /lib64/libnss_ldap.so.2 #11 0x0000002a977fd149 in _nss_ldap_readconfig () from /lib64/libnss_ldap.so.2 #12 0x0000002a977f7b21 in do_open () from /lib64/libnss_ldap.so.2 #13 0x0000002a977f84c0 in _nss_ldap_search_s () from /lib64/libnss_ldap.so.2 #14 0x0000002a977f8a48 in _nss_ldap_getbyname () from /lib64/libnss_ldap.so.2 #15 0x0000002a977f9300 in _nss_ldap_getpwuid_r () from /lib64/libnss_ldap.so.2 #16 0x0000002a96a5290d in getpwuid_r@@GLIBC_2.2.5 () from /lib64/tls/libc.so.6 #17 0x0000002a96a5228d in getpwuid () from /lib64/tls/libc.so.6 #18 0x0000002a964c3f35 in G_whoami () at whoami.c:64 #19 0x0000002a964c22f3 in G_sock_get_fname (name=0x507470 "x0")
at unix_socks.c:68 #20 0x0000002a9577c4b1 in R_open_driver () at io_sock.c:73 #21 0x0000000000402c98 in main (argc=1, argv=0x7fbfffea78) at main.c:47
-------------------------------------------- Managed by Request Tracker
Subject: Segfault in several display modules on x86_64
Platform: GNU/Linux/x86_64
grass binary for platform: Compiled from Sources
GRASS Version: GRASS 6.1.cvs (2006) checkout 4/22/06
Segfault in several display modules (d.vect, d.zoom) on x86_64, Suse 9.2.
uname -a:
Linux node0 2.6.5-7.244_lustre.1.4.6smp #1 SMP Sat Feb 18 17:33:39 EST 2006 x86_64 x86_64 x86_64 GNU/Linux
For both d.vect and d.zoom SIGSEGV can be traced to G_whoami () at whoami.c:64. Here is GDB stack trace:
#2 0x0000002a95deb05b in db_version (driver=0x50c4b8,
client_version=0x50c4bc, driver_version=0x50c4c0) at c_version.c:20 #3 0x0000002a97be6a01 in __db_e_attach () from /usr/lib64/tls/libdb-4.2.so
libdb is calling db_version, expecting to call its own function of
that name, but it's actually calling the one in libgrass_dbmiclient.
I'm not sure that there's any solution other than to rename the DBMI
functions to use a different prefix (one which isn't already used by a
common system library).
On Thu, Apr 27, 2006 at 05:24:19PM +0100, Glynn Clements wrote:
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4349
> -------------------------------------------------------------------------
>
> Subject: Segfault in several display modules on x86_64
>
> Platform: GNU/Linux/x86_64
> grass binary for platform: Compiled from Sources
> GRASS Version: GRASS 6.1.cvs (2006) checkout 4/22/06
>
> Segfault in several display modules (d.vect, d.zoom) on x86_64, Suse 9.2.
>
> uname -a:
>
> Linux node0 2.6.5-7.244_lustre.1.4.6smp #1 SMP Sat Feb 18 17:33:39 EST 2006 x86_64 x86_64 x86_64 GNU/Linux
>
> For both d.vect and d.zoom SIGSEGV can be traced to G_whoami () at whoami.c:64. Here is GDB stack trace:
> #2 0x0000002a95deb05b in db_version (driver=0x50c4b8,
> client_version=0x50c4bc, driver_version=0x50c4c0) at c_version.c:20
> #3 0x0000002a97be6a01 in __db_e_attach () from /usr/lib64/tls/libdb-4.2.so
libdb is calling db_version, expecting to call its own function of
that name, but it's actually calling the one in libgrass_dbmiclient.
I'm not sure that there's any solution other than to rename the DBMI
functions to use a different prefix (one which isn't already used by a
common system library).
> libdb is calling db_version, expecting to call its own function of
> that name, but it's actually calling the one in libgrass_dbmiclient.
>
> I'm not sure that there's any solution other than to rename the DBMI
> functions to use a different prefix (one which isn't already used by
> a common system library).
Maybe
db_gversion
That's for that one function, there are lots of generic-named fns in the
dmbi lib like db_delete() etc..
maybe make them all dbmi_* ? I guess gdb_ is no good..
> > libdb is calling db_version, expecting to call its own function of
> > that name, but it's actually calling the one in libgrass_dbmiclient.
> >
> > I'm not sure that there's any solution other than to rename the DBMI
> > functions to use a different prefix (one which isn't already used by
> > a common system library).
>
> Maybe
>
> db_gversion
That's for that one function, there are lots of generic-named fns in the
dmbi lib like db_delete() etc..
maybe make them all dbmi_* ? I guess gdb_ is no good..
DB_*
?
That's what I thought. Then I remembered that the linker might not be
case sensitive. Then, I realised that if the linker isn't case
sensitive, using GRASS in a GTK+ is out of the question, as libgis
(G_*) will conflict with glib (g_*), e.g. G_malloc() vs g_malloc().
DBMI_* would probably be safe enough.
In any case, renaming all of the db_* functions isn't really an option
Doing it by hand is out of the question (275 source files). A script
to change identifiers beginning with db_ might change variable or type
names.
Fortunately, the Berkely DB library only exports a few functions
beginning with "db_" (the main interface is via function pointers in
the DB structure). Apart from the 19 db_env_set_func_* functions, it
only exports:
db_create
db_env_create
db_strerror
db_version
db_version is the only one which currently conflicts with the DBMI
library.
