db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Calfee (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2475) invalid checksum
Date Thu, 28 Jun 2007 01:32:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508706
] 

James Calfee commented on DERBY-2475:
-------------------------------------

Basically the same thing has happened to me twice now.  I'm using 10.2.2.0 on Sun's Java 1.5
and Ubuntu.  I have a single character column that got hit both times.  I can select all the
data from other columns just fine.  

This is occurs using the embedded driver with only one parameter create=true.  All settings
are out-of-the-box.  I have added some code recently to purge a cache in some another table
which may have aggravated this bug.    It is very irregular and I'm having to restore backups
and reset a sequence to recover from it ;-(  .. I only wish I knew which (if an) older version
of Derby is free from this error.  I did see a post back in 2005 about this so I'm not so
sure if downgrading could help (or perhaps that was really a disk error).  It this case, does
not look like a disk error since the corruption is so confined and happened in the exact same
place on both occasions.

I have been doing routine table compression successfully for some time now.

Please let me know if I can help.

ERROR XSDG2: Invalid checksum on Page Page(679,Container(0, 19472)), expected=232,875,440,
on-disk version=4,193,292,366, page dump follows: Hex dump:
00000000: 0075 0000 0001 0000 0000 0000 0004 0003  .u..............
00000010: 0000 000a 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0001 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0406 0008  ................
00000040: 0004 0000 3e72 002a 0028 6338 3765 3239  .....r....c87e29
00000050: 3936 3630 6137 3962 6433 6565 3737 6465  9660a79bd3ee77de
... snip ... Lots of zeros omitted
00007fd0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007fe0: 0000 0000 0000 10b1 486e 0000 0764 094d  .......ᄆHn...d.M
00007ff0: 0000 003c 0728 0000 0000 0000 f9f0 904e  ..............ミN

        at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
        at org.apache.derby.impl.store.raw.data.StoredPage.validateChecksum(Unknown Source)
        at org.apache.derby.impl.store.raw.data.StoredPage.initFromData(Unknown Source)
        at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown Source)
        at org.apache.derby.impl.services.cache.CachedItem.takeOnIdentity(Unknown Source)
        at org.apache.derby.impl.services.cache.Clock.addEntry(Unknown Source)
        at org.apache.derby.impl.services.cache.Clock.find(Unknown Source)
        at org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(Unknown Source)
        at org.apache.derby.impl.store.raw.data.FileContainer.getNextHeadPage(Unknown Source)
        at org.apache.derby.impl.store.raw.data.BaseContainer.getNextPage(Unknown Source)
        at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getNextPage(Unknown Source)
        at org.apache.derby.impl.store.access.conglomerate.GenericScanController.positionAtNextPage(Unknown
Source)
        at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(Unknown
Source)
        at org.apache.derby.impl.store.access.heap.HeapScan.fetchNextGroup(Unknown Source)
        at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(Unknown Source)
        at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(Unknown
Source)
        at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
Source)
        at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
        at net.spamcomplaint.dao.JunkMailDAO.getJunkIds(JunkMailDAO.java:337)
        at net.spamcomplaint.swing.MessagePanel.loadMessages(MessagePanel.java:136)
        at net.spamcomplaint.swing.MessagePanel.<init>(MessagePanel.java:92)
        at net.spamcomplaint.swing.ApplicationPanel.<init>(ApplicationPanel.java:49)
        at net.spamcomplaint.swing.ApplicationFrame.createAndShowGUI(ApplicationFrame.java:35)
        at net.spamcomplaint.swing.ApplicationFrame.<init>(ApplicationFrame.java:20)
        at net.spamcomplaint.App.main(App.java:301)
Shutting down Derby...


> invalid checksum
> ----------------
>
>                 Key: DERBY-2475
>                 URL: https://issues.apache.org/jira/browse/DERBY-2475
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.2.0
>         Environment: windows xp, notebook, possibly broken hard drive!
>            Reporter: Fabian Merki
>            Priority: Critical
>         Attachments: defekt2.zip
>
>
> one of my customers gets on a notebook the following exception:
> ----------------------------------------------------------------
> 2007-03-17 09:01:53.042 GMT:
>  Booting Derby version The Apache Software Foundation - Apache Derby - 10.2.2.0 - (485682):
instance c013800d-0111-5f21-a736-000002cd2118
> on database directory C:\Programme\merkisoft\kursverwaltung\database\kurs  
> Database Class Loader started - derby.database.classpath=''
> ------------  BEGIN SHUTDOWN ERROR STACK -------------
> ERROR XSDG2: Invalid checksum on Page Page(28,Container(0, 1248)), expected=3'455'715'557,
on-disk version=3'357'396'866, page dump follows: Hex dump
>  
> hex dump => see attachment
>  
> i'm using the embedded version together with hibernate on the notebook.
> when i transfer the db to my pc and execute select * from <all tables> i get no
errors at all.
> we checked the disk about 3 times (with error correction): no result and it still happens.
> when i create a new db on the notebook it happens after a while again.
> the db is about 35 mb. i could put it somewhere for developers (please email me).
>  
> i've seen someone else having a similar problem but i couldn't find a solution yet.
>  
> any help is very welcome!
>  
> ------------------
> hi bryan
> thanks for the quick reply! i tried to answer your questions. i hope it
> helps.
> > Does this happen for this customer over and over?
> > Or did it happen only once?
> yes only that, but it happend 6 times.
> > Is the customer able to provoke the error on demand?
> i tried without success but i keep testing it.
> > Can you relate the exception to any particular action that the customer
> > is taking in your application?
> till now no.
> > If it has happened multiple times, is it always the same page on
> > the same container? Or is the location different each time?
> we installed the app serveral times and i think the following lines are per
> installation (so per installation it happend on the same page):
> org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
> Page(28,Container(0, 1248)), expected=3'455'715'557, on-disk
> version=3'357'396'866, page dump follows: Hex dump:
> org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
> Page(461,Container(0, 1248)), expected=3'908'279'257, on-disk
> version=137'782'528, page dump follows: Hex dump:
> org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
> Page(482,Container(0, 1248)), expected=4'113'528'744, on-disk
> version=44'301'386, page dump follows: Hex dump:
> org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
> Page(702,Container(0, 944)), expected=2'598'292'545, on-disk
> version=3'174'535'138, page dump follows: Hex dump:
> org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
> Page(2767,Container(0, 944)), expected=2'067'623'629, on-disk
> version=2'180'532'620, page dump follows: Hex dump:
> org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
> Page(99,Container(0, 1248)), expected=242'030'294, on-disk
> version=3'389'026'885, page dump follows: Hex dump:
>  > When the exception happens, are there any follow-on symptoms?
> yes, my app crashes ;-((
> i'm not shure how well i reinit the db connection.
> > Or did > the application seem to behave properly after the user shut it
> > down and restarted it? Can the customer later access the data properly
> > on their notebook? Or do you have to move the files to another machine
> > in order to access the data?
> restarts did not help as far as i know. but but when i copied it onto my
> harddrive it was ok.
> > thanks,
> thank you!
> fabian
> thanks
> fabian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message