[tode_st] Odd messageAsString

  createStone -u http://gsdevkit.github.io/GsDevKit_home/GemStoneGCI.ston -i GemStoneGCI -l GemStoneGCI -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston gci_330 3.3.0
  createClient -t pharo gci_50 -v Pharo5.0 -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston
  startClient gci_50 -s gci_330

On Mon, Apr 18, 2016 at 2:14 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm getting an odd result from GsGci32xErrSType>>messageAsString running the test GsGciClientForwarderTest>>testClientForwarderSend1 :

  GemStone Error (2336):  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'#'foo'.lientForwarder'

I assume that the #messageAsString should be:

  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'

and the extra nonsense at the end is probably there because these are supposed to be null terminated strings, and perhaps the memory is not properly zeroed between calls? Or something else? We can't rule out a GemStone bug, but this is pretty fundamental and not likely to make it past QA (possible -- but not likely :).

Hi Dale,

Yes, sorry I saw that issue as well and I asked Esteban at that point. I think Esteban was at PharoDays and couldn't answered me. 

I also think that data is not properly zeroed between calls and I pointed out Esteban where I thought it could be related.

I also thought it could be a gemstone bug, but I reproduced the problem in an old gemtools / tode, and I was getting the CORRECT result, so I think GemStone is indeed making it's job and clear it.

 

Anyway this result is as of commit 0a4287a for the GemStone-GCI project and includes both client and server-side code --- I'm working my way through a different issue, so this isn't a show stopper for me ... but when you have time, it would help to figure out what's happening here.

Did you find a reproducible test case? For me, I got it putting a wrong username/password and try the login test. However... I cannot reproduce (at unit test level) to have something PREVIOUSLY in the data ( like in this case the #'foo'.lientForwarder ). Were you able to reproduce this?

Anyway...not a showstopper either to check if a fix solves the issue or not as it should be cleared anyway.

 

With a recent GsDevKit_home checkout the following will set you up with a stone and client ready for action:

  createStone -u http://gsdevkit.github.io/GsDevKit_home/GemStoneGCI.ston -i GemStoneGCI -l GemStoneGCI -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston gci_330 3.3.0
  createClient -t pharo gci_50 -v Pharo5.0 -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston
  startClient gci_50 -s gci_330

Thanks Dale. I will ping back Esteban,

On 04/18/2016 10:23 AM, Mariano Martinez Peck wrote:

On Mon, Apr 18, 2016 at 2:14 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm getting an odd result from GsGci32xErrSType>>messageAsString running the test GsGciClientForwarderTest>>testClientForwarderSend1 :

  GemStone Error (2336):  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'#'foo'.lientForwarder'

I assume that the #messageAsString should be:

  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'

and the extra nonsense at the end is probably there because these are supposed to be null terminated strings, and perhaps the memory is not properly zeroed between calls? Or something else? We can't rule out a GemStone bug, but this is pretty fundamental and not likely to make it past QA (possible -- but not likely :).

Hi Dale,

Yes, sorry I saw that issue as well and I asked Esteban at that point. I think Esteban was at PharoDays and couldn't answered me. 

I also think that data is not properly zeroed between calls and I pointed out Esteban where I thought it could be related.

I also thought it could be a gemstone bug, but I reproduced the problem in an old gemtools / tode, and I was getting the CORRECT result, so I think GemStone is indeed making it's job and clear it.

Yeah I'd of thought this kind of problem would be pretty widely seen if it was a GemStone bug ...

 

Anyway this result is as of commit 0a4287a for the GemStone-GCI project and includes both client and server-side code --- I'm working my way through a different issue, so this isn't a show stopper for me ... but when you have time, it would help to figure out what's happening here.

Did you find a reproducible test case? For me, I got it putting a wrong username/password and try the login test. However... I cannot reproduce (at unit test level) to have something PREVIOUSLY in the data ( like in this case the #'foo'.lientForwarder ). Were you able to reproduce this?

Anyway...not a showstopper either to check if a fix solves the issue or not as it should be cleared anyway.

Just running GsGciClientForwarderTest>>testClientForwarderSend1 is reproducable for me ... but that is in an image where I have made other ffi calls ...

 

With a recent GsDevKit_home checkout the following will set you up with a stone and client ready for action:

  createStone -u http://gsdevkit.github.io/GsDevKit_home/GemStoneGCI.ston -i GemStoneGCI -l GemStoneGCI -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston gci_330 3.3.0
  createClient -t pharo gci_50 -v Pharo5.0 -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston
  startClient gci_50 -s gci_330

Thanks Dale. I will ping back Esteban,

I hope to fix the underlying bug pretty soon now and continue with the minimal tode work, but if necessary we can come back to this commit and test things out...

Thanks for your quick response ...

Dale

If you are talking about ExternalAddress >> replaceFrom: start to: stop with: replacement startingAt: repStart 

then...you got the same conclusion as I did.

On Mon, Apr 18, 2016 at 3:34 PM, Dale Henrichs <[hidden email]> wrote:

I think I've fixed the odd message... #messageAsString: was using #copyWithout: when it should have been using #copyUpTo: ... at least I think this is the problem ... looks better in one case, will let you know if it doesn't imporove all of the error messgae strings ...

Dale

On 04/18/2016 10:29 AM, Dale Henrichs wrote:

On 04/18/2016 10:23 AM, Mariano Martinez Peck wrote:

On Mon, Apr 18, 2016 at 2:14 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm getting an odd result from GsGci32xErrSType>>messageAsString running the test GsGciClientForwarderTest>>testClientForwarderSend1 :

  GemStone Error (2336):  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'#'foo'.lientForwarder'

I assume that the #messageAsString should be:

  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'

and the extra nonsense at the end is probably there because these are supposed to be null terminated strings, and perhaps the memory is not properly zeroed between calls? Or something else? We can't rule out a GemStone bug, but this is pretty fundamental and not likely to make it past QA (possible -- but not likely :).

Hi Dale,

Yes, sorry I saw that issue as well and I asked Esteban at that point. I think Esteban was at PharoDays and couldn't answered me. 

I also think that data is not properly zeroed between calls and I pointed out Esteban where I thought it could be related.

I also thought it could be a gemstone bug, but I reproduced the problem in an old gemtools / tode, and I was getting the CORRECT result, so I think GemStone is indeed making it's job and clear it.

Yeah I'd of thought this kind of problem would be pretty widely seen if it was a GemStone bug ...

 

Anyway this result is as of commit 0a4287a for the GemStone-GCI project and includes both client and server-side code --- I'm working my way through a different issue, so this isn't a show stopper for me ... but when you have time, it would help to figure out what's happening here.

Did you find a reproducible test case? For me, I got it putting a wrong username/password and try the login test. However... I cannot reproduce (at unit test level) to have something PREVIOUSLY in the data ( like in this case the #'foo'.lientForwarder ). Were you able to reproduce this?

Anyway...not a showstopper either to check if a fix solves the issue or not as it should be cleared anyway.

Just running GsGciClientForwarderTest>>testClientForwarderSend1 is reproducable for me ... but that is in an image where I have made other ffi calls ...

 

With a recent GsDevKit_home checkout the following will set you up with a stone and client ready for action:

  createStone -u http://gsdevkit.github.io/GsDevKit_home/GemStoneGCI.ston -i GemStoneGCI -l GemStoneGCI -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston gci_330 3.3.0
  createClient -t pharo gci_50 -v Pharo5.0 -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston
  startClient gci_50 -s gci_330

Thanks Dale. I will ping back Esteban,

I hope to fix the underlying bug pretty soon now and continue with the minimal tode work, but if necessary we can come back to this commit and test things out...

Thanks for your quick response ...

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Mariano
http://marianopeck.wordpress.com

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

On Mon, Apr 18, 2016 at 3:44 PM, Dale Henrichs <[hidden email]> wrote:

I'm not ... it's the #messageAsString method that was added (by you?) to improve the results of #message ... so it's a method in GsGci32xErrSType that "we own" that was incorrect ...

mmmm yes, I added #messageAsString because otherwise, as it's a FFI array instance, it looked as an array of chars...with nulls... very ugly and impossible to read. So..that was my method to convert it to a normal string. 

 

I am not sure #copyUpTo: is the correct way, as I remember having this null characters instances in the middle (like white spaces between words).

Could you try a login test with wrong password and see #messageAsString ?

I think the issue that you might thinking about is the fact that #message is not correct (thus #messageAsString:)?

yes!

 

Dale

On 04/18/2016 11:37 AM, Mariano Martinez Peck wrote:

If you are talking about ExternalAddress >> replaceFrom: start to: stop with: replacement startingAt: repStart 

then...you got the same conclusion as I did.

On Mon, Apr 18, 2016 at 3:34 PM, Dale Henrichs <[hidden email]> wrote:

I think I've fixed the odd message... #messageAsString: was using #copyWithout: when it should have been using #copyUpTo: ... at least I think this is the problem ... looks better in one case, will let you know if it doesn't imporove all of the error messgae strings ...

Dale

On 04/18/2016 10:29 AM, Dale Henrichs wrote:

On 04/18/2016 10:23 AM, Mariano Martinez Peck wrote:

On Mon, Apr 18, 2016 at 2:14 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm getting an odd result from GsGci32xErrSType>>messageAsString running the test GsGciClientForwarderTest>>testClientForwarderSend1 :

  GemStone Error (2336):  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'#'foo'.lientForwarder'

I assume that the #messageAsString should be:

  MessageNotUnderstood occurred (error 2010), a Set does not understand  #'send1'

and the extra nonsense at the end is probably there because these are supposed to be null terminated strings, and perhaps the memory is not properly zeroed between calls? Or something else? We can't rule out a GemStone bug, but this is pretty fundamental and not likely to make it past QA (possible -- but not likely :).

Hi Dale,

Yes, sorry I saw that issue as well and I asked Esteban at that point. I think Esteban was at PharoDays and couldn't answered me. 

I also think that data is not properly zeroed between calls and I pointed out Esteban where I thought it could be related.

I also thought it could be a gemstone bug, but I reproduced the problem in an old gemtools / tode, and I was getting the CORRECT result, so I think GemStone is indeed making it's job and clear it.

Yeah I'd of thought this kind of problem would be pretty widely seen if it was a GemStone bug ...

 

Anyway this result is as of commit 0a4287a for the GemStone-GCI project and includes both client and server-side code --- I'm working my way through a different issue, so this isn't a show stopper for me ... but when you have time, it would help to figure out what's happening here.

Did you find a reproducible test case? For me, I got it putting a wrong username/password and try the login test. However... I cannot reproduce (at unit test level) to have something PREVIOUSLY in the data ( like in this case the #'foo'.lientForwarder ). Were you able to reproduce this?

Anyway...not a showstopper either to check if a fix solves the issue or not as it should be cleared anyway.

Just running GsGciClientForwarderTest>>testClientForwarderSend1 is reproducable for me ... but that is in an image where I have made other ffi calls ...

 

With a recent GsDevKit_home checkout the following will set you up with a stone and client ready for action:

  createStone -u http://gsdevkit.github.io/GsDevKit_home/GemStoneGCI.ston -i GemStoneGCI -l GemStoneGCI -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston gci_330 3.3.0
  createClient -t pharo gci_50 -v Pharo5.0 -z $GS_HOME/shared/repos/GemStone-GCI/.smalltalk.ston
  startClient gci_50 -s gci_330

Thanks Dale. I will ping back Esteban,

I hope to fix the underlying bug pretty soon now and continue with the minimal tode work, but if necessary we can come back to this commit and test things out...

Thanks for your quick response ...

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Mariano
http://marianopeck.wordpress.com

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Mariano
http://marianopeck.wordpress.com

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.