Discussion:
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
(too old to reply)
David Sitsky
2008-03-31 00:24:30 UTC
Permalink
I have an intensive data-processing application which utilises Apache
Lucene and Derby, using 6 quad-core machines running Vista SP1 and/or
Vista Server 2008.

I have found after 5 or 10 hours of processing, one or a couple of my
worker processes start reporting the following error in the derby.log file:

ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))

The worker process never seems to recover. Derby locates the error,
reboots the database, but seems to inevitably report the same error
again. It is always page 1313, and what is extra strange is it doesn't
matter which machine it occurs on, it is always page 1313! I know 13 is
unlikely, but twice is a row must be extra unlucky. :)

The quad-core machines have been configured with both hardware and
software raid, but the same error has been seen. Windows does not
report any disk errors in the event log.

The error is difficult to reproduce. My runs typically run for 24
hours, involving 22 separate JVM processes spread across the machines,
each running their own Derby embedded database. Sometimes I can get
through the run without any issues - sometimes I might see one or two
processes with this issue, and it seems to pick a different quad-core
machine each time, so the possibility of a hardware error seems like
unlikely, especially given it is always page 1313.

I have tried both 10.3.1.4 and 10.3.2.1 with the same results.

Lucene doesn't report any problems with its index, so given all the
above evidence, I am starting to lean more to a software issue than
hardware.

I have attached three derby.log files from different machines. Does
anyone have any ideas what might be causing this?
--
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com Fax: +61 2 9212 6902
Narayanan
2008-03-31 04:17:20 UTC
Permalink
Hi David,

You might find the following links containing earlier discussions on the
similar issue useful,

http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741

http://www.nabble.com/Derby-crash-%28urgent%29-tt16217446.html#a16265491

https://issues.apache.org/jira/browse/DERBY-2475

Narayanan
Post by David Sitsky
I have an intensive data-processing application which utilises Apache
Lucene and Derby, using 6 quad-core machines running Vista SP1 and/or
Vista Server 2008.
I have found after 5 or 10 hours of processing, one or a couple of my
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
The worker process never seems to recover. Derby locates the error,
reboots the database, but seems to inevitably report the same error
again. It is always page 1313, and what is extra strange is it
doesn't matter which machine it occurs on, it is always page 1313! I
know 13 is unlikely, but twice is a row must be extra unlucky. :)
The quad-core machines have been configured with both hardware and
software raid, but the same error has been seen. Windows does not
report any disk errors in the event log.
The error is difficult to reproduce. My runs typically run for 24
hours, involving 22 separate JVM processes spread across the machines,
each running their own Derby embedded database. Sometimes I can get
through the run without any issues - sometimes I might see one or two
processes with this issue, and it seems to pick a different quad-core
machine each time, so the possibility of a hardware error seems like
unlikely, especially given it is always page 1313.
I have tried both 10.3.1.4 and 10.3.2.1 with the same results.
Lucene doesn't report any problems with its index, so given all the
above evidence, I am starting to lean more to a software issue than
hardware.
I have attached three derby.log files from different machines. Does
anyone have any ideas what might be causing this?
David Sitsky
2008-03-31 05:20:32 UTC
Permalink
Hi Narayanan,

Yes I have seen those links already. I have spent quite a bit of time
confirming that my hardware is not at fault before posting here.

I think you'll agree to see exactly the same page number failing on 3
separate machines lends itself more to being a software issue than a
hardware one.

The OS has not reported any disk issues at all.

Cheers,
David
Post by Narayanan
Hi David,
You might find the following links containing earlier discussions on the
similar issue useful,
http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741
http://www.nabble.com/Derby-crash-%28urgent%29-tt16217446.html#a16265491
https://issues.apache.org/jira/browse/DERBY-2475
Narayanan
Post by David Sitsky
I have an intensive data-processing application which utilises Apache
Lucene and Derby, using 6 quad-core machines running Vista SP1 and/or
Vista Server 2008.
I have found after 5 or 10 hours of processing, one or a couple of my
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
The worker process never seems to recover. Derby locates the error,
reboots the database, but seems to inevitably report the same error
again. It is always page 1313, and what is extra strange is it
doesn't matter which machine it occurs on, it is always page 1313! I
know 13 is unlikely, but twice is a row must be extra unlucky. :)
The quad-core machines have been configured with both hardware and
software raid, but the same error has been seen. Windows does not
report any disk errors in the event log.
The error is difficult to reproduce. My runs typically run for 24
hours, involving 22 separate JVM processes spread across the machines,
each running their own Derby embedded database. Sometimes I can get
through the run without any issues - sometimes I might see one or two
processes with this issue, and it seems to pick a different quad-core
machine each time, so the possibility of a hardware error seems like
unlikely, especially given it is always page 1313.
I have tried both 10.3.1.4 and 10.3.2.1 with the same results.
Lucene doesn't report any problems with its index, so given all the
above evidence, I am starting to lean more to a software issue than
hardware.
I have attached three derby.log files from different machines. Does
anyone have any ideas what might be causing this?
--
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com Fax: +61 2 9212 6902
David Sitsky
2008-03-31 22:20:51 UTC
Permalink
For what its worth, I did another run last night on my 6 quad-core
system. This time I had the derby issue happen for a JVM process on
machine 1, two processes on machine 4, and one on machine 5. I run four
JVM processes per quad-core machine.

All the JVM processes have roughly the same data processing rate, but
the issue happens at different times into the load. The problem
occurred around time 420, 480, 800 and 900 minutes into the load for the
four problematic processes.

As is always the case - all of them report the issue on page 1313, and
there are no disk errors reported by Windows.

Any ideas what the problem might be? I am happy to invest the time to
track down the issue, but I need some guidance from the Derby gurus.

I noticed 1313 in binary is 10100100001. Does this have special
significance within Derby's binary tree structures?

Cheers,
David
Post by David Sitsky
Hi Narayanan,
Yes I have seen those links already. I have spent quite a bit of time
confirming that my hardware is not at fault before posting here.
I think you'll agree to see exactly the same page number failing on 3
separate machines lends itself more to being a software issue than a
hardware one.
The OS has not reported any disk issues at all.
Cheers,
David
Post by Narayanan
Hi David,
You might find the following links containing earlier discussions on
the similar issue useful,
http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741
http://www.nabble.com/Derby-crash-%28urgent%29-tt16217446.html#a16265491
https://issues.apache.org/jira/browse/DERBY-2475
Narayanan
Post by David Sitsky
I have an intensive data-processing application which utilises Apache
Lucene and Derby, using 6 quad-core machines running Vista SP1 and/or
Vista Server 2008.
I have found after 5 or 10 hours of processing, one or a couple of my
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
The worker process never seems to recover. Derby locates the error,
reboots the database, but seems to inevitably report the same error
again. It is always page 1313, and what is extra strange is it
doesn't matter which machine it occurs on, it is always page 1313! I
know 13 is unlikely, but twice is a row must be extra unlucky. :)
The quad-core machines have been configured with both hardware and
software raid, but the same error has been seen. Windows does not
report any disk errors in the event log.
The error is difficult to reproduce. My runs typically run for 24
hours, involving 22 separate JVM processes spread across the
machines, each running their own Derby embedded database. Sometimes
I can get through the run without any issues - sometimes I might see
one or two processes with this issue, and it seems to pick a
different quad-core machine each time, so the possibility of a
hardware error seems like unlikely, especially given it is always
page 1313.
I have tried both 10.3.1.4 and 10.3.2.1 with the same results.
Lucene doesn't report any problems with its index, so given all the
above evidence, I am starting to lean more to a software issue than
hardware.
I have attached three derby.log files from different machines. Does
anyone have any ideas what might be causing this?
Dyre.Tjeldvoll-UdXhSnd/
2008-04-01 07:37:30 UTC
Permalink
Post by David Sitsky
For what its worth, I did another run last night on my 6 quad-core
system. This time I had the derby issue happen for a JVM process on
machine 1, two processes on machine 4, and one on machine 5. I run
four JVM processes per quad-core machine.
All the JVM processes have roughly the same data processing rate, but
the issue happens at different times into the load. The problem
occurred around time 420, 480, 800 and 900 minutes into the load for
the four problematic processes.
Just to clarify: These jvm processes do not access the SAME database, do
they?
--
dt
David Sitsky
2008-04-01 10:11:36 UTC
Permalink
Post by Dyre.Tjeldvoll-UdXhSnd/
Post by David Sitsky
For what its worth, I did another run last night on my 6 quad-core
system. This time I had the derby issue happen for a JVM process on
machine 1, two processes on machine 4, and one on machine 5. I run
four JVM processes per quad-core machine.
All the JVM processes have roughly the same data processing rate, but
the issue happens at different times into the load. The problem
occurred around time 420, 480, 800 and 900 minutes into the load for
the four problematic processes.
Just to clarify: These jvm processes do not access the SAME database, do
they?
No - they all have their own embedded derby database.

Cheers,
David
Stanley Bradbury
2008-03-31 22:51:03 UTC
Permalink
Post by David Sitsky
Hi Narayanan,
Yes I have seen those links already. I have spent quite a bit of time
confirming that my hardware is not at fault before posting here.
I think you'll agree to see exactly the same page number failing on 3
separate machines lends itself more to being a software issue than a
hardware one.
The OS has not reported any disk issues at all.
Cheers,
David
Post by Narayanan
Hi David,
You might find the following links containing earlier discussions on
the similar issue useful,
http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741
http://www.nabble.com/Derby-crash-%28urgent%29-tt16217446.html#a16265491
https://issues.apache.org/jira/browse/DERBY-2475
Narayanan
Post by David Sitsky
I have an intensive data-processing application which utilises
Apache Lucene and Derby, using 6 quad-core machines running Vista
SP1 and/or Vista Server 2008.
I have found after 5 or 10 hours of processing, one or a couple of
my worker processes start reporting the following error in the
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
The worker process never seems to recover. Derby locates the error,
reboots the database, but seems to inevitably report the same error
again. It is always page 1313, and what is extra strange is it
doesn't matter which machine it occurs on, it is always page 1313!
I know 13 is unlikely, but twice is a row must be extra unlucky. :)
The quad-core machines have been configured with both hardware and
software raid, but the same error has been seen. Windows does not
report any disk errors in the event log.
The error is difficult to reproduce. My runs typically run for 24
hours, involving 22 separate JVM processes spread across the
machines, each running their own Derby embedded database. Sometimes
I can get through the run without any issues - sometimes I might see
one or two processes with this issue, and it seems to pick a
different quad-core machine each time, so the possibility of a
hardware error seems like unlikely, especially given it is always
page 1313.
I have tried both 10.3.1.4 and 10.3.2.1 with the same results.
Lucene doesn't report any problems with its index, so given all the
above evidence, I am starting to lean more to a software issue than
hardware.
I have attached three derby.log files from different machines. Does
anyone have any ideas what might be causing this?
Hi Dave -

The problem is happening on the Page 0 [the first page] of conglomerate
1313 (the conglomerateId) - you can see what table/index this
corresponds to with the following query:

select CONGLOMERATENUMBER, CONGLOMERATENAME
from sys.sysconglomerates
where conglomeratenumber = 1313;

From the errors in your log I suspect this to be the table or one of
the indexes of the failing query listed:
INSERT INTO text_table (guidhigh, guid, data)

Does your database reboot without any errors after the shutdown/crash?

You wrote: " /Derby locates the error, reboots the database, but seems
to inevitably report the same error again./ "

I assume this means you get the same exception when the database reboots
(indicating the change was written to the transaction log and is
replaying the error as the database attempts to recover when the db
reboots).

From looking at your derby.log files I noted two things that may not be
important but, because you are having trouble you might try changing to
see if it makes any difference:

1) the databases are created in the directory D:\temp... If you
suspect that this directory is every purged/cleared then this in not a
good place to have database files. The files should be in a permanent
and secure location.

2) the attempts to reboot the database after is shutdown are almost
instantaneous (well less than a second between the SHUTDOWN timestamp
and the BOOTING timestamp). I assume the database is being rebooted
within the same JVM and would like to see if adding a pause between
reboots to insure that all objects have been garbage collected changes
anything. Alternately if you shutdown the system then attempt to
access the database from a newly started JVM ( I would use IJ) and still
get the exception this shows that uncollected derby objects are not the
problem.

Hope this helps.
David Sitsky
2008-04-01 01:35:12 UTC
Permalink
Hi Stanley,

Thanks for your message.
Post by Stanley Bradbury
The problem is happening on the Page 0 [the first page] of conglomerate
1313 (the conglomerateId) - you can see what table/index this
select CONGLOMERATENUMBER, CONGLOMERATENAME
from sys.sysconglomerates
where conglomeratenumber = 1313;
From the errors in your log I suspect this to be the table or one of
INSERT INTO text_table (guidhigh, guid, data)
That's correct - there are essentially two types of queries which seem
to cause the issue on the text_table table. Either the insertion of
blob data into text_table (it is compressed text), or a select call
check for the existence of an entry given guidhigh and guid.
Post by Stanley Bradbury
Does your database reboot without any errors after the shutdown/crash?
You wrote: " /Derby locates the error, reboots the database, but seems
to inevitably report the same error again./ "
I assume this means you get the same exception when the database reboots
(indicating the change was written to the transaction log and is
replaying the error as the database attempts to recover when the db
reboots).
That's right. I just tried explicitly restarting the application by
killing off the process (there is a nanny process which detects this and
automatically restarts it). However I still get the same derby errors
on startup.
Post by Stanley Bradbury
1) the databases are created in the directory D:\temp... If you
suspect that this directory is every purged/cleared then this in not a
good place to have database files. The files should be in a permanent
and secure location.
In this case the d:\ is a raid array, and even though it is written to a
directory called temp, nothing is being deleted from it. There are no
virus scanners running either.
Post by Stanley Bradbury
anything. Alternately if you shutdown the system then attempt to
access the database from a newly started JVM ( I would use IJ) and still
get the exception this shows that uncollected derby objects are not the
problem.
Yes - I have confirmed that restarting the JVM still reports the same
error on startup I am afraid.

Any ideas on what to check for now?
--
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com Fax: +61 2 9212 6902
David Sitsky
2008-04-01 03:41:39 UTC
Permalink
Hi Stanley,
Post by Stanley Bradbury
The problem is happening on the Page 0 [the first page] of conglomerate
1313 (the conglomerateId) - you can see what table/index this
select CONGLOMERATENUMBER, CONGLOMERATENAME
from sys.sysconglomerates
where conglomeratenumber = 1313;
From the errors in your log I suspect this to be the table or one of
INSERT INTO text_table (guidhigh, guid, data)
I ran ij from the command-line, and connected to one of the problematic
databases after killing the load. Sure enough 1313 refers to the
primary key of text_table (there are no other indexes defined on this
table). This is what is output:

CONGLOMERATENUMBER |CONGLOMERATENAME

--------------------------------------------------------------------------------
---------------------------------------------------------------------
1313 |SQL080331145004520

This is the SQL we used to create this table:

CREATE TABLE text_table (guidhigh BIGINT NOT NULL,
guid BIGINT NOT NULL,
data BLOB (1G) NOT NULL,
PRIMARY KEY (guidhigh, guid))

What is interesting is if I perform a simple query on text_table, I get
the following:

ij> select count(*) from text_table;
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313)),
expected=304,608,373, on-disk version=2,462,088,751, page dump follows:
Hex dump:
00000000: 0076 0000 0001 0000 0000 0000 27ea 0000 .v..............
00000010: 0000 0006 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0001 0000 0000 0000 0000 0000 ................
....

Same as my application. I have also noticed the connection is
automatically closed, as is the case in my application if I try and
perform another operation.

ij> select count(*) from text_table;
ERROR 08003: No current connection.

Reconnecting to the database has the same result.

So I guess it is not surprising now that conglomerate 1313 is always
returned since all worker processes create the same database on startup.
However the corruption is always happening on page 0. If we were
experiencing true disk problems, I'd expect the page number to be random
across the machines.

Any ideas on what to try next?
--
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com Fax: +61 2 9212 6902
Stanley Bradbury
2008-04-01 18:00:20 UTC
Permalink
Post by David Sitsky
Hi Stanley,
Post by Stanley Bradbury
The problem is happening on the Page 0 [the first page] of
conglomerate 1313 (the conglomerateId) - you can see what table/index
select CONGLOMERATENUMBER, CONGLOMERATENAME
from sys.sysconglomerates
where conglomeratenumber = 1313;
From the errors in your log I suspect this to be the table or one of
INSERT INTO text_table (guidhigh, guid, data)
I ran ij from the command-line, and connected to one of the
problematic databases after killing the load. Sure enough 1313 refers
to the primary key of text_table (there are no other indexes defined
CONGLOMERATENUMBER |CONGLOMERATENAME
--------------------------------------------------------------------------------
---------------------------------------------------------------------
1313 |SQL080331145004520
CREATE TABLE text_table (guidhigh BIGINT NOT NULL,
guid BIGINT NOT NULL,
data BLOB (1G) NOT NULL,
PRIMARY KEY (guidhigh, guid))
What is interesting is if I perform a simple query on text_table, I
ij> select count(*) from text_table;
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313)),
expected=304,608,373, on-disk version=2,462,088,751, page dump
00000000: 0076 0000 0001 0000 0000 0000 27ea 0000 .v..............
00000010: 0000 0006 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0001 0000 0000 0000 0000 0000 ................
....
Same as my application. I have also noticed the connection is
automatically closed, as is the case in my application if I try and
perform another operation.
ij> select count(*) from text_table;
ERROR 08003: No current connection.
Reconnecting to the database has the same result.
So I guess it is not surprising now that conglomerate 1313 is always
returned since all worker processes create the same database on
startup. However the corruption is always happening on page 0. If we
were experiencing true disk problems, I'd expect the page number to be
random across the machines.
Any ideas on what to try next?
Hi Dave -
The good news is that it looks like you do not have to recover this
database from backups because:
1) since you can boot the database using IJ the corruption is not in
the transaction log (I assume you did not directly modify or delete any
files in the database directory tree in order to bypass recovery - *yes,
I have seen people do this*)
2) since the corruption is in an index you should be able to drop and
recreate the index thus restoring the index without any data loss.

I also have an idea that might get around it. Since the problem is with
an index and during a data load (I am assuming the load is a one time
database initialization streaming lots of data?) then I would try
creating the index AFTER loading the data rather than declaring the
index in the table Create statement. If the problem involves handling a
large number of database pages and the index pages at the same time
separating the activities will avoid it. Doing this also insures that
index statistics are created (for more info on this see:
http://wiki.apache.org/db-derby/CheckingForIndexStatistics)

As for the cause of the problem I can't be sure but since this happens
repeatedly and with different physical files it sounds like the problem
is not with the physical disk surface (I think the RAID architecture
helps protect against this type of failure anyway).

I'd like to see this problem captured in an JIRA entry. You have
provided a lot of good information here and the results of performing a
load then creating the Primary Key will narrow it down more. My
gut-level feel is that reproducing this will be hard without an
environment similar to yours. With the multiple processors and the RAID
array I imagine it is a pretty fast machine and this may be exposing a
thread synchronization issue in Derby (or not). Having your information
and stack traces may give the stores folks enough information to perform
a code inspection for this or other issues. Would you file a JIRA
describing your processing, the machine environment, the JVM and attach
your derby log files?
David Sitsky
2008-04-02 05:19:02 UTC
Permalink
Post by Stanley Bradbury
Hi Dave -
The good news is that it looks like you do not have to recover this
1) since you can boot the database using IJ the corruption is not in
the transaction log (I assume you did not directly modify or delete any
files in the database directory tree in order to bypass recovery - *yes,
I have seen people do this*)
Correct.
Post by Stanley Bradbury
2) since the corruption is in an index you should be able to drop and
recreate the index thus restoring the index without any data loss.
I also have an idea that might get around it. Since the problem is with
an index and during a data load (I am assuming the load is a one time
database initialization streaming lots of data?) then I would try
Yes.
Post by Stanley Bradbury
creating the index AFTER loading the data rather than declaring the
index in the table Create statement. If the problem involves handling a
large number of database pages and the index pages at the same time
separating the activities will avoid it. Doing this also insures that
http://wiki.apache.org/db-derby/CheckingForIndexStatistics)
Ok - we are restructuring the application, so that now, we can get away
with a primary key field of just an INTEGER, rather than the two BIGINT
columns. Also, because of the restructure, we don't need to check for
the existence of a duplicate record before insertion, so we can now
create the primary key once all of the data has been loaded.

I'm in the process of merging these changes in, and will try to do some
more big loads to see if this has made the problem go away. I'll let
you know how I go in the next few days.
Post by Stanley Bradbury
As for the cause of the problem I can't be sure but since this happens
repeatedly and with different physical files it sounds like the problem
is not with the physical disk surface (I think the RAID architecture
helps protect against this type of failure anyway).
For these tests - I am just running software "scary raid" (raid-0), but
the OS doesn't report any disk failures.
Post by Stanley Bradbury
I'd like to see this problem captured in an JIRA entry. You have
provided a lot of good information here and the results of performing a
load then creating the Primary Key will narrow it down more. My
gut-level feel is that reproducing this will be hard without an
environment similar to yours. With the multiple processors and the RAID
array I imagine it is a pretty fast machine and this may be exposing a
thread synchronization issue in Derby (or not). Having your information
and stack traces may give the stores folks enough information to perform
a code inspection for this or other issues. Would you file a JIRA
describing your processing, the machine environment, the JVM and attach
your derby log files?
Will do - once I have more information from the load with the modified
application, I'll create the JIRA entry with all the relevant information.

Thanks so much for your advice.
--
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com Fax: +61 2 9212 6902
David Sitsky
2008-04-03 05:40:08 UTC
Permalink
Post by David Sitsky
Ok - we are restructuring the application, so that now, we can get away
with a primary key field of just an INTEGER, rather than the two BIGINT
columns. Also, because of the restructure, we don't need to check for
the existence of a duplicate record before insertion, so we can now
create the primary key once all of the data has been loaded.
As expected, our loading doesn't exhibit the problem now with the above
change.

Incidentally, we had a customer being hit with this problem yesterday,
on their own hardware, which was an AMD64 dual core 4200 with 4 GB of
ram running 32 bit XP pro.

I will create the JIRA entry in the next day or two - the fact this has
now been seen on an external site on completely different hardware / OS
shows we are probably dealing with a software issue.
--
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com Fax: +61 2 9212 6902
Stanley Bradbury
2008-04-08 14:42:38 UTC
Permalink
Post by David Sitsky
Post by David Sitsky
Ok - we are restructuring the application, so that now, we can get
away with a primary key field of just an INTEGER, rather than the two
BIGINT columns. Also, because of the restructure, we don't need to
check for the existence of a duplicate record before insertion, so we
can now create the primary key once all of the data has been loaded.
As expected, our loading doesn't exhibit the problem now with the
above change.
Incidentally, we had a customer being hit with this problem yesterday,
on their own hardware, which was an AMD64 dual core 4200 with 4 GB of
ram running 32 bit XP pro.
I will create the JIRA entry in the next day or two - the fact this
has now been seen on an external site on completely different hardware
/ OS shows we are probably dealing with a software issue.
Thanks for thorough job in reporting this problem.

Loading...