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

[Mariano Martinez Peck via Glass]

On Wed, Jan 28, 2015 at 8:14 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> 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 <
> glass at lists.gemtalksystems.com> 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 listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
>
>  --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150128/78fedb30/attachment-0001.html>