q=?ISO-8859-1?Q?=FD'?=

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

q=?ISO-8859-1?Q?=FD'?=

Leandro Caniglia
From time to time, quite randomly, the debugger jumps for a good reason, except that it does with a strange label that in my case contains the characters qý'. Further inspection of the window's label reveals that the intended message was partially overwritten with 71 FD 27 00 (hex representation). The original string is not modified in any way, it is just the copy that ends up in the label which gets overwritten.

I wonder whether someone else in this list has experienced a similar behavior. My actual concern is not related to the wrong label. I'm actually worried about possible side effects that this behavior might be creating when the label looks fine.

A couple of days ago I asked this question to Richie and Javier and they managed to give me good insights about the problem. Anyone interested may ask them too. I'm sure they will gladly share their findings in this list.

What I would like to know is whether somebody else has observed a similar behavior and has any explanation about it.

/Leandro
*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: q=?ISO-8859-1?Q?=FD'?=

SkogstadNielsen
Den 27-07-2011 20:11, Leandro Caniglia skrev:

> >From time to time, quite randomly, the debugger jumps for a good
> reason, except that it does with a strange label that in my case
> contains the characters qý'. Further inspection of the window's label
> reveals that the intended message was partially overwritten with 71 FD
> 27 00 (hex representation). The original string is not modified in any
> way, it is just the copy that ends up in the label which gets
> overwritten.
>
> I wonder whether someone else in this list has experienced a similar
> behavior. My actual concern is not related to the wrong label. I'm
> actually worried about possible side effects that this behavior might
> be creating when the label looks fine.
>
> A couple of days ago I asked this question to Richie and Javier and
> they managed to give me good insights about the problem. Anyone
> interested may ask them too. I'm sure they will gladly share their
> findings in this list.
>
> What I would like to know is whether somebody else has observed a
> similar behavior and has any explanation about it.
>
> /Leandro
> *** this signature added by listserv *** *** Visit
> http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive
> browsing and VSWE-L membership management ***
I have - but have no explanation- have not seen sideeffects

--
Søren Skogstad Nielsen
tlf: 50994638

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: q=?iso-8859-1?Q?=FD'?=

David Hari
In reply to this post by Leandro Caniglia

I have seen that too, occasionally. Except in my case, i think the data in the label was a little different (might just have been the ý character).

 

 

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Leandro Caniglia
Sent: Thursday, 28 July 2011 4:12 AM
To: [hidden email]
Subject: qý'

 

From time to time, quite randomly, the debugger jumps for a good reason, except that it does with a strange label that in my case contains the characters qý'. Further inspection of the window's label reveals that the intended message was partially overwritten with 71 FD 27 00 (hex representation). The original string is not modified in any way, it is just the copy that ends up in the label which gets overwritten.

 

I wonder whether someone else in this list has experienced a similar behavior. My actual concern is not related to the wrong label. I'm actually worried about possible side effects that this behavior might be creating when the label looks fine.

 

A couple of days ago I asked this question to Richie and Javier and they managed to give me good insights about the problem. Anyone interested may ask them too. I'm sure they will gladly share their findings in this list.

 

What I would like to know is whether somebody else has observed a similar behavior and has any explanation about it.

 

/Leandro

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: q=?iso-8859-1?Q?=FD'?=

Todor Todorov

I guess this is some kind of stack miss-alignment. There are some bugs that will trash the stack under certain circumstances.

 

But the address in question does look like some of the addresses where system DLL’s are loaded. Normally, the only places where those addresses are used is the DLL handle or the return addresses of a function in those DLLs. The return address to a DLL function is used on the stack and is very seldom seen other places. The one that Leandro wrote is quite clean address and appears more to be a DLL handle (address) than a return address. DLL handles are used in regard to API calls and are pushed on the stack. My guess is some stack issue. If this is only debugger issue (the ST debugger being the problem), then be it. But if bug in some error / exception or interrupt handler, than might be more serious.

 

I however have seen more often the “end of stack chain” error while debugging. It is related with blocks and block returns. I guess some bug in regard to the block environment / context. I didn’t have time to look more into the issue, but it is quite annoying and is often a debugging show-stopper.

 

 

PS: The text difference might be due to different Windows code-page or the DLL in question being loaded at different address.

 

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of David Hari
Sent: 28. juli 2011 00:58
To: [hidden email]
Subject: Re: qý'

 

I have seen that too, occasionally. Except in my case, i think the data in the label was a little different (might just have been the ý character).

 

 

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Leandro Caniglia
Sent: Thursday, 28 July 2011 4:12 AM
To: [hidden email]
Subject: qý'

 

From time to time, quite randomly, the debugger jumps for a good reason, except that it does with a strange label that in my case contains the characters qý'. Further inspection of the window's label reveals that the intended message was partially overwritten with 71 FD 27 00 (hex representation). The original string is not modified in any way, it is just the copy that ends up in the label which gets overwritten.

 

I wonder whether someone else in this list has experienced a similar behavior. My actual concern is not related to the wrong label. I'm actually worried about possible side effects that this behavior might be creating when the label looks fine.

 

A couple of days ago I asked this question to Richie and Javier and they managed to give me good insights about the problem. Anyone interested may ask them too. I'm sure they will gladly share their findings in this list.

 

What I would like to know is whether somebody else has observed a similar behavior and has any explanation about it.

 

/Leandro

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: q=?ISO-8859-1?Q?=FD'?=

Leandro Caniglia
Given my recent experience with this issue I can tell that it is not related to any DLL code. Unfortunately it is not easily reproducible, but trying many times I was occasionally able to make it apparent without calling any DLL.

I'm interested in this issue right now. But as soon as we have addressed it, I will turn my attention to the "end of stack" error that has been bothering all of us for years. Does anybody know how to reproduce it?

/Leandro

On Wed, Jul 27, 2011 at 8:54 PM, Todor Todorov <[hidden email]> wrote:

I guess this is some kind of stack miss-alignment. There are some bugs that will trash the stack under certain circumstances.

 

But the address in question does look like some of the addresses where system DLL’s are loaded. Normally, the only places where those addresses are used is the DLL handle or the return addresses of a function in those DLLs. The return address to a DLL function is used on the stack and is very seldom seen other places. The one that Leandro wrote is quite clean address and appears more to be a DLL handle (address) than a return address. DLL handles are used in regard to API calls and are pushed on the stack. My guess is some stack issue. If this is only debugger issue (the ST debugger being the problem), then be it. But if bug in some error / exception or interrupt handler, than might be more serious.

 

I however have seen more often the “end of stack chain” error while debugging. It is related with blocks and block returns. I guess some bug in regard to the block environment / context. I didn’t have time to look more into the issue, but it is quite annoying and is often a debugging show-stopper.

 

 

PS: The text difference might be due to different Windows code-page or the DLL in question being loaded at different address.

 

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of David Hari
Sent: 28. juli 2011 00:58

Subject: Re: qý'

 

I have seen that too, occasionally. Except in my case, i think the data in the label was a little different (might just have been the ý character).

 

 

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Leandro Caniglia
Sent: Thursday, 28 July 2011 4:12 AM
To: [hidden email]
Subject: qý'

 

From time to time, quite randomly, the debugger jumps for a good reason, except that it does with a strange label that in my case contains the characters qý'. Further inspection of the window's label reveals that the intended message was partially overwritten with 71 FD 27 00 (hex representation). The original string is not modified in any way, it is just the copy that ends up in the label which gets overwritten.

 

I wonder whether someone else in this list has experienced a similar behavior. My actual concern is not related to the wrong label. I'm actually worried about possible side effects that this behavior might be creating when the label looks fine.

 

A couple of days ago I asked this question to Richie and Javier and they managed to give me good insights about the problem. Anyone interested may ask them too. I'm sure they will gladly share their findings in this list.

 

What I would like to know is whether somebody else has observed a similar behavior and has any explanation about it.

 

/Leandro

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***