[Glass] Weird Gems crash when exporting sixx (corrupt error???)

Hi guys,

I am trying to export a "database" using SIXX. And there is one database in particular were the gem that runs the export crashes. This database is the "biggest" one, so memory issues may be related. The logs do not suggest out  of memory errors (I already have those in the past). I am running GemStone 3.1.0.5 with Seaside 3.1 and latest GLASS.

I do have the logs so I attach them. Both are logs from the same crash. 

Any idea what could be going on?

Thanks in advance,

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Thanks Dale. Of course, that happened while at was in holidays hehehehe.

Now I had the time to debug it and indeed, it was the UTF8 problem as you said. Basically, I had a string which contained a none UTF8 characters and therefore had a primitive fail in 

String >> encodeAsUTF8

"Encode receiver in UTF8 format.  Returns a Utf8 ."

<primitive: 468>

self _primitiveFailed: #encodeAsUTF8

So... you said this was a "known" issue. Should I report it somewhere? was it already fixed in newest gemstone?

Thanks, 

On Thu, Jan 8, 2015 at 7:13 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Mariano,

Okay, you do have a weird situation here ....

The "session must logout" error occurred at 2015-01-07T22:58:49.24770092964172-05:00 and the SigSegv occurred at 01/07/2015 23:11:25.502 EST with no intervening logout, so the second SigSegV might be a side-effect of the earlier error.

The "session must logout" is usually a consequence of an earlier error, but I don't see any other errors in the log, so perhaps there are continuations stashed in the object log or other intervening error handlers that have masked the error or ????

Anyway, one "known" error that results in a "session must logout" can occur when you get an InternalError (error 2261) while attempting to decode a utf8 encoded string that has certain invalid utf8 characters, but like I said there's no evidence that might have happened.

To isolate the SIXX problem and possibly get better information, you could try doing the SIXX export in an interactive topaz session then you should see any errors unfiltered by Seaside and fastCGI ...

Dale

On 01/07/2015 08:47 PM, Mariano Martinez Peck via Glass wrote:

Hi guys,

I am trying to export a "database" using SIXX. And there is one database in particular were the gem that runs the export crashes. This database is the "biggest" one, so memory issues may be related. The logs do not suggest out  of memory errors (I already have those in the past). I am running GemStone 3.1.0.5 with Seaside 3.1 and latest GLASS.

I do have the logs so I attach them. Both are logs from the same crash. 

Any idea what could be going on?

Thanks in advance,

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

On Wed, Jan 28, 2015 at 8:14 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

The bug was reported at internal bug 44291, and was fixed in 3.1.0.6 and 3.2, so we're good!

Hi Dale, good to know it was fixed. 

mmmmmmmm the server where I had this error was 3.1.0.6... maybe it also needed some changes at the error handler stuff in the scripts that start seaside gems?

Thanks

 

Dale

On 01/28/2015 02:50 PM, Mariano Martinez Peck wrote:

Thanks Dale. Of course, that happened while at was in holidays hehehehe.

Now I had the time to debug it and indeed, it was the UTF8 problem as you said. Basically, I had a string which contained a none UTF8 characters and therefore had a primitive fail in 

String >> encodeAsUTF8

"Encode receiver in UTF8 format.  Returns a Utf8 ."

<primitive: 468>

self _primitiveFailed: #encodeAsUTF8

So... you said this was a "known" issue. Should I report it somewhere? was it already fixed in newest gemstone?

Thanks, 

On Thu, Jan 8, 2015 at 7:13 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Mariano,

Okay, you do have a weird situation here ....

The "session must logout" error occurred at 2015-01-07T22:58:49.24770092964172-05:00 and the SigSegv occurred at 01/07/2015 23:11:25.502 EST with no intervening logout, so the second SigSegV might be a side-effect of the earlier error.

The "session must logout" is usually a consequence of an earlier error, but I don't see any other errors in the log, so perhaps there are continuations stashed in the object log or other intervening error handlers that have masked the error or ????

Anyway, one "known" error that results in a "session must logout" can occur when you get an InternalError (error 2261) while attempting to decode a utf8 encoded string that has certain invalid utf8 characters, but like I said there's no evidence that might have happened.

To isolate the SIXX problem and possibly get better information, you could try doing the SIXX export in an interactive topaz session then you should see any errors unfiltered by Seaside and fastCGI ...

Dale

On 01/07/2015 08:47 PM, Mariano Martinez Peck via Glass wrote:

Hi guys,

I am trying to export a "database" using SIXX. And there is one database in particular were the gem that runs the export crashes. This database is the "biggest" one, so memory issues may be related. The logs do not suggest out  of memory errors (I already have those in the past). I am running GemStone 3.1.0.5 with Seaside 3.1 and latest GLASS.

I do have the logs so I attach them. Both are logs from the same crash. 

Any idea what could be going on?

Thanks in advance,

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com