List:General Discussion« Previous MessageNext Message »
From:Randall Severy Date:August 23 2002 6:31pm
Subject:Re: Still trying to build libmysqld.a on Tru64
View as plain text  
At 11:28 AM 8/23/2002 -0500, Dan Nelson wrote:
>That actually shouldn't be a problem.  Binutils and gcc configures
>itself to match the file formats of the host system.

Dan,

      Yup, that's what I thought as well, which is why I struggled for 
nearly a
week to figure it out.  The linker simply refused to find (resulting in
"Undefined" errors) symbols in libmysqld.a that were compiled from C++ source
files (objects built from C source files were fine) when libmysqld.a was built
using GNU ar instead of the Compaq ar utility.

>(I fixed the line wrapping.  Try not to wrap logfile lines; it makes
>them hard to read.)

     Oops, sorry, that was done automatically by my e-mail client, I'll 
turn it
off for this message.

>This dump is an assertion failure in mysqld (lib_vio.c, line 118),
>possibly because earlier crashes had corrupted the database files.
>Corrupt Innodb tables are more likely to kill mysqld than MyISAM
>tables, but only because they are not supposed to ever corrupt in the
>first place :)

      Actually, there are no database files at all, since any attempts to 
create
the database also crash as well.  And I'm not using Innodb tables (I'm 
building
MySQL using "--without-innodb").

>This crash was probably due to a NULL (or wild) pointer dereference in
>vio_read().  Can you build wsd-install with debugging, so we can see
>the arguments to the functions on the stack?  Also, jump to frame 7 and
>run the "dump" command, which will list all the local variables for
>that function.

      As it turned out, this crash was a red herring, as the wsd-install 
program
was still linked with the GCC-built libmysqld.a, which has all kinds of other
problems.  I rebuilt wsd-install with debugging and with the 4.0.2 libmysqld.a
and got a completely different crash (but nearly identical to the 'wsd' 
program
crash):

Assertion failed: vio->packets, file lib_vio.c, line 118
Abort process (core dumped)

Core file produced from executable 'wsd-install'
Thread 1 terminated at PC 0x3ff8057d728 by signal ABRT

 >0  0x3ff8057d728 in __nxm_thread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libpthread.so
#1  0x3ff80576560 in pthread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libpthread.so
#2  0x3ff80581ae8 in UnknownProcedure2FromFile99(0x3ffc01842c8, 0x6, 0x1, 
0x1, 0x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#3  0x3ff807e3aa0 in UnknownProcedure16FromFile0(0x3ffc01842c8, 0x6, 0x1, 
0x1, 0x14, 0x3ffc0184000) in /usr/shlib/libexc.so
#4  0x3ff807e3e90 in exc_raise_signal_exception(0x3ffc01842c8, 0x6, 0x1, 
0x1, 0x14, 0x3ffc0184000) in /usr/shlib/libexc.so
#5  0x3ff80578040 in UnknownProcedure282FromFile0(0x3ffc01842c8, 0x6, 0x1, 
0x1,0x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#6  0x3ff800d5270 in __sigtramp(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libc.so
#7  0x3ff8057d728 in __nxm_thread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libpthread.so
#8  0x3ff80576560 in pthread_kill(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libpthread.so
#9  0x3ff8058da08 in UnknownProcedure6FromFile108(0x3ffc01842c8, 0x6, 0x1, 
0x1,0x14, 0x3ffc0184000) in /usr/shlib/libpthread.so
#10 0x3ff8013b0b4 in __tis_raise(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libc.so
#11 0x3ff8019f570 in raise(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libc.so
#12 0x3ff801c2800 in abort(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libc.so
#13 0x3ff801c22b0 in __assert(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in /usr/shlib/libc.so
#14 0x1200ce2f0 in vio_read(vio=0x140071300, 
buf=0x1408c0d60="\377\033\004Unknown table \'wsd_users\'", size=4) "lib_vio
#15 0x1200e04b4 in my_real_read(net=0x140042380, complen=0x11fffa700) 
"net_serv.cc":533
#16 0x1200e09bc in my_net_read(net=0x140
#17 0x1200d8000 in net_safe_read(mysql=0x140042380) "libmysqld.c":95
#18 0x1200d94d0 in read_rows(mysql=0x140042380, mysql_fields=0x0, fields=5) 
"libmysqld.c":620
#19 0x1200db18c in mysql_read_query_result(mysql=0x140042380) 
"libmysqld.c":1163
#20 0x1200db670 in mysql_real_query(mysql=0x140042380, 
query=0x11fffa9a8="drop table wsd_users", length=20) "libmysqld.c":1284
#21 0x1200daf38 in mysql_query(mysql=0x140042380, query=0x11fffa9a8="drop 
table wsd_users") "libmysqld.c":1116
#22 0x1200a30d0 in query_db(query_string=0x11fffa9a8="drop table 
wsd_users") "webengine_db.c":1462
#23 0x12009c8b4 in load_database(table_filename=0x11fffbceb="wsd.dbschema", 
defprefix=0x11fffb130="wsd", dbprefix=0x11fffb188="") "webinstall.c":2970
#24 0x12009f680 in process_install() "webinstall.c":3706
#25 0x12009faa0 in main(argc=3, argv=0x11fffc018) "webinstall.c":3780
#26 0x120091968 in __start(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 
0x3ffc0184000) in wsd-install

      It looks like both problems occur when a database error occurs (this one
was "Unknown table", the previous one was "Table doesn't exist").  When
initializing the database, the wsd-install program issues a "drop table" 
command
prior to every "create table" command.  For brand-new databases, the error 
from
the "drop table" command is ignored.  But instead of the normal MySQL error
handling, these errors appear to be triggering that assert call in vio_read.

Best Regards,

Randall Severy


Randall Severy    severy@stripped    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@stripped    http://www.cyberteams.com
Frederick, MD
(301) 682-8885          "Building effective teams in cyberspace"
1-888-832-5575


Thread
Still trying to build libmysqld.a on Tru64Randall Severy16 Aug
  • startup automaticPaulo Azevedo IEG16 Aug
    • Re: startup automaticPaul DuBois16 Aug
  • Re: Still trying to build libmysqld.a on Tru64Dan Nelson16 Aug
    • Re: Still trying to build libmysqld.a on Tru64Randall Severy16 Aug
      • Re: Still trying to build libmysqld.a on Tru64Dan Nelson16 Aug
        • Re: Still trying to build libmysqld.a on Tru64Randall Severy23 Aug
          • Re: Still trying to build libmysqld.a on Tru64Dan Nelson23 Aug
            • Re: Still trying to build libmysqld.a on Tru64Randall Severy23 Aug
              • Re: Still trying to build libmysqld.a on Tru64Dan Nelson23 Aug
                • Re: Still trying to build libmysqld.a on Tru64Randall Severy24 Aug
                  • Re: Re: Still trying to build libmysqld.a on Tru64Egor Egorov26 Aug