[BUG] Gpfault wnen try debug block in workspace...

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

[BUG] Gpfault wnen try debug block in workspace...

Pavel
Hi ALL!
I'm playing in Workspace and found a problem when try debug a small chunk of
this code:

****************
r:=Random new.
g:=[((r next)*1000000) floor].
" or with any of  thats block ....
g:=[(1.1 asFloat *1) floor ].
g:=[(1.1 asFloat *1) +0 ].
g:=[(1.1 asFloat *1) *1 ].
g:=[(1.1 asFloat *1) rounded ].
g:=[(1 * 1.1 asFloat ) rounded ].  "

" !!! and now try debug line below "
g value  " <= when here F11 - I'v got a gpFault "

******************

Pavel

PS. I hope such small report will appear useful to OA...


Reply | Threaded
Open this post in threaded view
|

Re: Gpfault wnen try debug block in workspace...

Jeff M.
I would like to second this. I was working with COM objects, and just
figured that it was something I'm doing. But it is very random, and
sometimes works perfectly. Also, if I encapsulate my code in a class
method and run it, everything is fine.

Jeff M.


Reply | Threaded
Open this post in threaded view
|

Re: Gpfault wnen try debug block in workspace...

Blair McGlashan-4
"Jeff M." <[hidden email]> wrote in message
news:[hidden email]...
>I would like to second this. I was working with COM objects, and just
> figured that it was something I'm doing. But it is very random, and
> sometimes works perfectly. Also, if I encapsulate my code in a class
> method and run it, everything is fine.

Jeff, I don't think this is related. Pavel's issue reproduces reliably for
me, and is (I suspect) due to an issue around the mapping between release
and debug versions of the underlying method - i.e. it is more an issue with
the debugger and/or the compiler. The behaviour you describe sounds far more
like a memory overwrite issue, or perhaps you've handed out a reference to
an object that is being prematurely GC'd. Workstation code and code in
classes are exactly the same as far as the VM is concerned. The difference
might be the longevity of some of the objects.

Bottom line is, if you are doing external interfacing code and experience
random crashes then suspect first your interfacing code. Check the buffer
sizes and lifetimes of the buffers. Suspect second the COM object itself.
Only lastly consider whether there is a bug in Dolphin. There are bugs in
Dolphin, but not too many that result in random GPFs. The very nature of the
continuously running environment, the high level of leverage in the
framework, and the ever increasing battery of tests, tends to mean these
kind of issues get worked out fairly early in the development and test
cycle. Not to say they aren't there, but they will be obscure since most
code paths through the lower levels of the system are very well covered.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Gpfault wnen try debug block in workspace...

Blair McGlashan-4
In reply to this post by Pavel
"Pavel" <[hidden email]> wrote in message
news:[hidden email]...

> Hi ALL!
> I'm playing in Workspace and found a problem when try debug a small chunk
> of
> this code:
>
> ****************
> r:=Random new.
> g:=[((r next)*1000000) floor].
> " or with any of  thats block ....
> g:=[(1.1 asFloat *1) floor ].
> g:=[(1.1 asFloat *1) +0 ].
> g:=[(1.1 asFloat *1) *1 ].
> g:=[(1.1 asFloat *1) rounded ].
> g:=[(1 * 1.1 asFloat ) rounded ].  "
>
> " !!! and now try debug line below "
> g value  " <= when here F11 - I'v got a gpFault "
>
> ******************
>
> Pavel
>
> PS. I hope such small report will appear useful to OA...
>

Thanks Pavel. It reproduces well for me,. and has been duly recorded. I
suspect a compiler or debugger issue in attempting to map from the release
build of the block to a debuggable one.

Regards

Blair