Mailing List Archive


Back to the month index Back to the list index
Jason Wilkes (jason@eurosurf.com)
Wed, 07 Apr 1999 21:38:23 +0100 

Message-ID: <370BC23F.75D4FE23@eurosurf.com>
Date: Wed, 07 Apr 1999 21:38:23 +0100
From: Jason Wilkes <jason@eurosurf.com>
Subject: Hit by Sig 11 - Possible data corruption?

Hi Folks,

        I've recently been trial-ling mSQL, but have hit some problems with the
msql server crashing.
Can some-one provide some help / insight ?? ( There seems to be a lot of
questions re sig 11, but not many answers :-(

I think mime may be due to corrupt data in a particular field ( as I can
select around the field, but as soon as I select the actual field the
database goes away. )

I have included below some debug output of MSQL_DEBUG trace & malloc, as
well as messages etc.

The data field in question is a TEXT field so I can't see what the data
"corruption" could be. Below is a hexdump of the .dat and .ofl files
detailing the field contents ( which look like ok text to me ).

Any clues ? - I always suppose that the overflow pointer from the .dat
file points to the wrong place in the .ofl file, but I don't know
how/where to check.

any help would be appreciated
jason

( hexdump of .dat - field is 40 chars starting with the "T" of The )
00129440 00 00 00 00 00 00 01 6b 00 00 00 23 00 00 00 54
|.......k...#...T|
00129450 68 65 20 53 65 63 72 65 74 61 72 79 2c 20 3c 62 |he
Secretary, <b|
00129460 72 3e 54 68 65 20 41 73 73 6f 63 69 61 74 69 6f |r>The
Associatio|
00129470 6e 20 6f 66 20 52 6f 01 14 00 00 00 ff ff ff ff |n of
Ro.........|

(hexdump of .ofl - field starts with "yal Navy" etc etc ).
00001200 ff ff ff ff 79 61 6c 20 4e 61 76 79 20 4f 66 66 |....yal
Navy Off|
00001210 69 63 65 72 73 2c 20 3c 62 72 3e 37 30 20 50 6f |icers,
<br>70 Po|
00001220 72 63 68 65 73 74 65 72 20 54 65 72 72 61 63 65 |rchester
Terrace|
00001230 2c 20 3c 62 72 3e 4c 4f 4e 44 4f 4e 20 3c 62 72 |,
<br>LONDON <br|
00001240 3e 57 32 20 33 54 50 00 00 00 00 00 00 00 00 00 |>W2
3TP.........|
00001250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|

Debug with malloc:
[msqld] Allocating 42 bytes at 4C300 (msqld.c:1084)
[msqld] Allocating 7 bytes at 4A160 (msql_lex.c:324)
[msqld] Freeing address 4A150 (msql_lex.c:377)
[msqld] Allocating 9 bytes at 4A170 (msql_lex.c:324)
[msqld] Allocating 9 bytes at 4A180 (msql_lex.c:324)
[msqld] Freeing address 4A160 (msql_lex.c:377)
[msqld] Allocating 5 bytes at 4A190 (msql_lex.c:324)
[msqld] Allocating 72 bytes at 50800 (msql_proc.c:219)
[msqld] Freeing address 4A170 (msql_yacc.y:776)
[msqld] Allocating 156 bytes at 4EC00 (msql_proc.c:585)
[msqld] Freeing address 50800 (msql_proc.c:647)
[msqld] Freeing address 4A180 (msql_lex.c:377)
[msqld] Allocating 6 bytes at 4A1A0 (msql_lex.c:324)
[msqld] Allocating 6 bytes at 4A1B0 (msql_lex.c:324)
[msqld] Freeing address 4A190 (msql_lex.c:377)
[msqld] Allocating 6 bytes at 4A1C0 (msql_lex.c:324)
[msqld] Allocating 80 bytes at 50B00 (msql_proc.c:885)
[msqld] Freeing address 4A1A0 (msql_yacc.y:428)
[msqld] Freeing address 4A1B0 (msql_lex.c:377)
[msqld] Allocating 4 bytes at 4A1D0 (msql_lex.c:324)
[msqld] Allocating 4 bytes at 4A1E0 (msql_lex.c:324)
[msqld] Freeing address 4A1C0 (msql_lex.c:377)
[msqld] Allocating 2 bytes at 4A1F0 (msql_lex.c:324)
[msqld] Allocating 72 bytes at 50D80 (msql_proc.c:219)
[msqld] Freeing address 4A1D0 (msql_yacc.y:776)
[msqld] Freeing address 4A1E0 (msql_lex.c:377)
[msqld] Allocating 4 bytes at 4A200 (msql_lex.c:324)
[msqld] Allocating 4 bytes at 4A210 (msql_lex.c:324)
[msqld] Freeing address 4A200 (msql_yacc.y:726)
[msqld] Allocating 408 bytes at 4F200 (msql_proc.c:796)
[msqld] Freeing address 50D80 (msql_proc.c:817)
[msqld] Freeing address 4A1F0 (msql_lex.c:377)
[msqld] Allocating 2 bytes at 4A220 (msql_lex.c:324)
[msqld] Allocating 88 bytes at 53080 (cra.c:428)
[msqld] Allocating 24 bytes at 371E0 (table.c:1616)
[msqld] Allocating 108 bytes at 53200 (varchar.c:289)

Hit by a sig 11

Forced server shutdown due to bad signal!

Forcing close on Socket 6
[msqld] Freeing address 37060 (msqld.c:165)

www# tail /var/log/messages
Apr 7 19:30:15 www login: ROOT LOGIN (root) ON ttyv0
Apr 7 19:51:34 www /kernel: pid 325 (msql2d), uid 1001: exited on
signal 6
Apr 7 20:12:18 www /kernel: pid 344 (msql2d), uid 1001: exited on
signal 6

Debug with Trace
www# [msqld] --> msqlInit()
[msqld] <-- msqlInit()
[msqld] --> msqlParseQuery()
[msqld] --> msqlCreateIdent()
[msqld] <-- msqlCreateIdent()
[msqld] --> msqlAddField()
[msqld] <-- msqlAddField()
[msqld] --> msqlAddTable()
[msqld] <-- msqlAddTable()
[msqld] --> msqlCreateIdent()
[msqld] <-- msqlCreateIdent()
[msqld] --> msqlCreateValue()
[msqld] <-- msqlCreateValue()
[msqld] --> msqlAddCond()
[msqld] <-- msqlAddCond()
[msqld] --> msqlProcessQuery()
[msqld] --> msqlSelect()
[msqld] --> msqlQualifyField()
[msqld] <-- msqlQualifyField()
[msqld] --> msqlQualifyConds()
[msqld] <-- msqlQualifyConds()
[msqld] --> msqlQualifyOrder()
[msqld] <-- msqlQualifyOrder()
[msqld] --> loadTableDef()
[msqld] --> readTableDef()
[msqld] <-- readTableDef()
[msqld] --> loadIndices()
[msqld] <-- loadIndices()
[msqld] --> initTable()
[msqld] <-- initTable()
[msqld] <-- loadTableDef()
[msqld] --> doSelect()
[msqld] --> msqlSetupFields()
[msqld] <-- msqlSetupFields()
[msqld] --> msqlSetupConds()
[msqld] <-- msqlSetupConds()
[msqld] --> initTable()
[msqld] <-- initTable()
[msqld] --> matchRow()

.....lots of matchRows :-)

[msqld] --> matchRow()
[msqld] <-- matchRow()
[msqld] --> matchRow()
[msqld] <-- matchRow()
[msqld] --> extractValues()

Hit by a sig 11

Forced server shutdown due to bad signal!

Forcing close on Socket 6
From mriehl@sarnoff.mitre.org Wed Apr 7 16:45:05 1999
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2])
        by services.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA26995
        for <msql-list@services.bunyip.com>; Wed, 7 Apr 1999 16:45:02 -0400 (EDT)
Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1])
        by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA15258
        for <msql-list@bunyip.com>; Wed, 7 Apr 1999 16:44:33 -0400 (EDT)
Received: from sarnoff.mitre.org (sarnoff.mitre.org [128.29.222.143])
        by mwunix.mitre.org (8.8.8/8.8.8) with ESMTP id QAA07619
        for <msql-list@bunyip.com>; Wed, 7 Apr 1999 16:44:29 -0400 (EDT)
Date: Wed, 7 Apr 1999 16:44:59 -0400 (EDT)
From: Mark Riehl <mriehl@sarnoff.mitre.org>
To: msql-list@bunyip.com
Subject: Platform Differences?
Message-ID: <Pine.LNX.4.05.9904071632340.753-100000@sarnoff.mitre.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

All,

I'm new to using msql, but couldn't find an answer to this in the FAQ. I
have an msql database on Solaris x86 machine that I'd like to get running
on a Linux machine. Here is one of the tables:

debug@APP00582[86] relshow -h APP00582 fbcb2.db sa_server

Database = fbcb2.db
Table = sa_server

 +-----------------+----------+--------+----------+--------------+
 | Field | Type | Length | Not Null | Unique Index |
 +-----------------+----------+--------+----------+--------------+
 | brdcst_urn | int | 4 | Y | N/A |
 | primary_svr_urn | int | 4 | Y | N/A |
 | secondary_svr_u | int | 4 | N | N/A |
 | data_type | int | 4 | Y | N/A |
 +-----------------+----------+--------+----------+--------------+

Looks fine. I tarred up the entire database, and sent it via binary FTP
to a Linux machine. If I run relshow, it shows me a correct list of all
the tables in each of the databases. However, if I try to look at an
individual table, I get the following:

sarnoff:~# relshow -h sarnoff fbcb2.db sa_server

Database = fbcb2.db
Table = sa_server

 +-----------------+----------+--------+----------+--------------+
 | Field | Type | Length | Not Null | Unique Index |
 +-----------------+----------+--------+----------+--------------+
 | | Unknown | 0 | N | N/A |
 | | Unknown | 0 | Y | N/A |
 | | Unknown | 4 | N | N/A |
 | | Unknown | 0 | N | N/A |
 | c | Unknown | 0 | Y | N/A |
 +-----------------+----------+--------+----------+--------------+
  

This is the same table I showed above, different machine. For some reason,
there is an extra field. I checked the versions as well - here are the
results off the Solaris x86 machine:

ROOT on APP00582>msqladmin -h APP00582 version

Version Details :-

        msqladmin version 2.0 Production Release
        mSQL server version 2.0 Production Release
        mSQL protocol version 23
        mSQL connection APP00582 via TCP/IP
        Target platform Solaris-2.6-i86pc

Configuration Details :-

        Default config file /users/cm/configmt/CM/3.x/cots/msql.conf
        TCP socket 1114
        UNIX socket /users/cm/configmt/CM/3.x/cots/msql2.sock
        mSQL user msql
        Admin user root
        Install directory /users/cm/configmt/CM/3.x/cots
        PID file location /users/cm/configmt/CM/3.x/cots/msql2.pid
        Memory Sync Timer 30
        Hostname Lookup True

*************************************************
Here are the results off the Linux machine:

sarnoff:~# msqladmin -h sarnoff version

Version Details :-

        msqladmin version 2.0.8
        mSQL server version 2.0.8
        mSQL protocol version 23
        mSQL connection sarnoff via TCP/IP
        Target platform Linux-2.0.35-i686

Configuration Details :-

        Default config file /usr/local/Hughes/msql.conf
        TCP socket 1114
        UNIX socket /home/mriehl/storm/iote/db/data/msql2.sock
        mSQL user root
        Admin user root
        Install directory /home/mriehl/storm/iote/db/data
        PID file location /home/mriehl/storm/iote/db/data/msql2d.pid
        Memory Sync Timer 30
        Hostname Lookup True

Does it matter that the Linux machine is a newer version of msql? Any
suggestions?

Thanks,
Mark 

--
Mark Riehl
The MITRE Corporation
mriehl@mitre.org
(732) 389-6752