GNOME.org
 

Re: [gnome-db] Segmentation Fault gda-test 1.1.99

On Wed, 2004-10-27 at 09:40, Bas Driessen wrote:
On Tue, 2004-10-26 at 22:17, Rodrigo Moya wrote: 
On Tue, 2004-10-26 at 21:28 +1000, Bas Driessen wrote:
> Hello,
> 
> Just to let you know that the gda-test application isn /testing fails
> in version 1.1.99 on my machine. It stops with a segmentation
> violation. I also get segfaults when running my application linked to
> 1.1.99. All works fine (including gda-test) with version 1.0.4
> 
> Just to let you know, since you are about to release 1.2, it may be
> worth a quick test to see if gda-test works on your machine. I am
> running FC2 x86_64 (AMD 64).
> 
> The tail of the gda-test output is as follows:
> 
> 
>         Column 0 - Row 49: This is a string
>         Column 1 - Row 49: 200
>         Column 2 - Row 49: FALSE
>         Column 3 - Row 49: 3.14
>         Column 4 - Row 49: Another string
>         Column 5 - Row 49: 4560.46
>                                                                                                                              
> =========================================
> = Testing GDA client API
> =========================================
> Data source = stocksql, User =
>         Provider capabilities...
>                 Aggregates: Supported
>                 Indexes: Supported
>                 Namespaces: Supported
>                 Procedures: Supported
>                 Sequences: Supported
>                 SQL: Supported
>                 Transactions: Supported
>                 Triggers: Supported
>                 Users: Supported
>                 Views: Supported
>                 XML queries: Not supported
>                 BLOBs: Supported
>                                                                                                                              
>         Provider reports version: PostgreSQL 7.4.2 on
> x86_64-redhat-linux-gnu, compiled by GCC x86_64-redhat-linux-gcc (GCC)
> 3.3.3 20040216 (Red Hat Linux 3.3.3-2.1)
>                                                                                                                              
>         Namespaces
>                 NONE
> Segmentation fault
> [bas ams testing]$
> 
> 
> I will try to locate why/where my appn falls over. If you need
> additional info, please let me know.
> 
it works on my machine. We will need you getting a backtrace of the
crash from gdb. Can you do that please? *

[*] $ gdb app
    (gdb) run
leave it running until it crashes, and
    (gdb) bt

Thanks for response Rodrigo,

Have been investigating further. The good news is that all appears to work fine with the latest CVS (26/10/2004) sources. Still I wanted to know why it did not work in 1.1.99, but for some reason gdb is not working properly on my x86_64 box even though I am using default FC2 installation. I get the following error when starting it.

...
...
This GDB was configured as "x86_64-redhat-linux-gnu"..."/opt/builds/gnome-db/libgda-1.1.99/testing/gda-test": not in executable format: File format not recognized
                                                                                                                            
(gdb)

I realize this is not a libgda issue, but just to let you know the background why I can not supply you with a bt at this stage. gdb is not working with any application btw, not just libgda related ones, even though gdb compiler flags are set.

When running autogen.sh to generate the Makefiles for the cvs version of libgda I got a couple of warnings. (see below). All appears to work fine, but just to let you know if it serious and requires fixing prior to 1.2 release.


Running automake-1.8...
doc/C/Makefile.am:18: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
libgda/Makefile.am:3: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
libsql/Makefile.am:3: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/bdb/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/firebird/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/freetds/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/ibmdb2/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/ldap/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/mdb/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/msql/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/mysql/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/odbc/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/oracle/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/postgres/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/sqlite/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/sybase/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/xbase/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
providers/xml/Makefile.am:4: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
report/libgda-report/Makefile.am:3: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
report/testing/Makefile.am:1: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
testing/Makefile.am:1: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')
tools/Makefile.am:17: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS')

Thanks,
Bas.

Just to follow up on this one, I got the gdb to work and the bt is as follows:

(Please note this is the seg fault running gda-test in 1.1.99. As mentioned before, the latest cvs appears to be in order again.)

#0  0x0000000000000000 in ?? ()
#1  0x0000002a958f541d in gda_postgres_recordset_get_n_rows (model=0x52e0b0) at gda-postgres-recordset.c:651
#2  0x0000002a95570568 in gda_data_model_get_n_rows (model=0x52e0b0) at gda-data-model.c:431
#3  0x0000000000402b91 in show_schema (cnc=0x52e0b0, schema=5361264, label=0x40564a "Databases") at client.c:46
#4  0x000000000040311d in open_connection (client=0x52c560, name=0x527f90 "stocksql", username=0x528090 "", password=0x52e040 "  R")
t client.c:130
#5  0x00000000004036ad in test_client () at client.c:202
#6  0x0000000000404148 in run_gda_test (user_data=0x52e0b0) at gda-test.c:32
#7  0x0000002a95576ea3 in idle_cb (user_data=0x52e0b0) at gda-init.c:76
#8  0x000000379ef27b3e in g_child_watch_add () from
/usr/lib64/libglib-2.0.so.0
#9  0x000000379ef24c02 in g_main_depth () from /usr/lib64/libglib-2.0.so.0
#10 0x000000379ef25c34 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#11 0x000000379ef25f1e in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#12 0x000000379ef264cd in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#13 0x0000002a95576f41 in gda_main_run (init_func=0x404130 <run_gda_test>,
user_data=0x0) at gda-init.c:112
#14 0x0000000000404184 in main (argc=5431472, argv=0x51ce70) at gda-test.c:42
(gdb) quit

Thanks,
Bas.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]