Board index » cppbuilder » BDS 2006 "De{*word*81} Freeze / Hang" Analysis

BDS 2006 "De{*word*81} Freeze / Hang" Analysis


2007-05-23 06:42:06 PM
cppbuilder17
Hi.
There were several other threads about this topic, but I still see no resolution
to this problem, and I'm very worried that this bug will still be present in
BCB2007 - so here we go again.
First some information:
=======================
- BDS2006 with all Updates and all hotfixes applied
- Tested on several systems (Windows XP (32bit), SP2, all hotfixes)
- All systems are properly maintained with very few applications running
Symptoms:
=========
Arriving on a breakpoint and inspecting the call-stack freezes the de{*word*81} and
the IDE completely. The same effect happens when trying to open the "local
variables". If one of those debug windows is opened in the debug layout the IDE
/de{*word*81} freezes when it hits the breakpoint. This effect is reproducible and
happens every time when I try to access the call stack. I used always the same
source and function in this tests, but I have several sources where this effect
occurs.
Inspecting the BDS process with SysInternals Process Explorer you can see that
it uses 100% cpu resources, all of it in the BDS main thread. The call stack for
this thread looks like this:
ntoskrnl.exe+0x5909
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
bordbk100N.dll!POSTEDHOOKPROC+0x1a83
bordbk100N.dll!POSTEDHOOKPROC+0x1e85
bordbk100N.dll!POSTEDHOOKPROC+0x1f4a
bordbk100N.dll!POSTEDHOOKPROC+0x1211
bordbk100N.dll!POSTEDHOOKPROC+0x4f2
bordbk100N.dll!POSTEDHOOKPROC+0x6d5
bordbk100N.dll!POSTEDHOOKPROC+0x261
bordbk100N.dll!isDbkLoggingOn$qv+0x5d43
bordbk100N.dll!isDbkLoggingOn$qv+0x5ff8
bordbk100N.dll!isDbkLoggingOn$qv+0x60d5
bordbk100N.dll!isDbkLoggingOn$qv+0x6d69
dbkdebugide100.bpl!Debug+0x33
coreide100.bpl!Callstac+0x85
coreide100.bpl!Callstac+0x38
coreide100.bpl!Callstac+0x5a
coreide100.bpl!Callstac+0xa8
Inspecting the stack multiple times one can see that it seems to be stuck.
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]
ntoskrnl.exe!ZwAlertThread+0x28
hal.dll!ExReleaseFastMutex+0x1a
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]
As you can see most of the stack is always the same and only the functions above
'bordbk100N.dll!POSTEDHOOKPROC+0x10af' change.
Inspecting the BDS-process with "Process Monitor" shows that there is no file or
registry activity at all.
Experiments:
============
I made some experiments to narrow the causes for this behaviour.
1. I almost completely removed the code from the source where I observed the
freeze. Only a few headers were left. No precompiled headers were used. Effect: none
2. I turned off precompiled headers for the project. Effect: none
3. I made a release build of all targets used in the project. Effect: none
4. I manually deleted all TDS files (btw: why are there any after a release
build?). Effect: none
5. I reduced the complexity of the function called to almost zero: void
func(void) { asm { db 0xcc; } }. Effect: none
6. I called the function in question at another time of the program: freeze
disappeared. *Note*: The very same function-call-stack-inspection one time
freezes the IDE, and in the other call context, everything is ok.
Conclusions:
============
I think it is safe to assume, that there is a bug in the de{*word*81} when
inspecting stacks.
Resolution:
===========
So what is to do next? I have spent many hours to narrow down the possible
causes for this problem - but without the sources for the de{*word*81}, I think
there is nothing reasonable I could do more.
So would please anyone at Codegear look into this? I promise to buy BDS2007 if
you fix this bug. :)
Thanks a bundle.
Best Regards
Eike Petersen
Cologne, Germany
 
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Please add a report on this at qc.codegear.com.
CodeGear don't officially look in these ngs.
If you can include a simple project with steps to show the
problem it is even more likely to get fixed.
(That is if it has not already been fixed)
Thanks, Pete
"Eike Petersen" < XXXX@XXXXX.COM >wrote in
message news: XXXX@XXXXX.COM ...
Quote
Hi.

There were several other threads about this topic, but I
still see no resolution to this problem, and I'm very
worried that this bug will still be present in BCB2007 -
so here we go again.

First some information:
=======================
- BDS2006 with all Updates and all hotfixes applied
- Tested on several systems (Windows XP (32bit), SP2, all
hotfixes)
- All systems are properly maintained with very few
applications running

Symptoms:
=========
Arriving on a breakpoint and inspecting the call-stack
freezes the de{*word*81} and the IDE completely. The same
effect happens when trying to open the "local variables".
If one of those debug windows is opened in the debug
layout the IDE /de{*word*81} freezes when it hits the
breakpoint. This effect is reproducible and happens every
time when I try to access the call stack. I used always
the same source and function in this tests, but I have
several sources where this effect occurs.

Inspecting the BDS process with SysInternals Process
Explorer you can see that it uses 100% cpu resources, all
of it in the BDS main thread. The call stack for this
thread looks like this:

ntoskrnl.exe+0x5909
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
bordbk100N.dll!POSTEDHOOKPROC+0x1a83
bordbk100N.dll!POSTEDHOOKPROC+0x1e85
bordbk100N.dll!POSTEDHOOKPROC+0x1f4a
bordbk100N.dll!POSTEDHOOKPROC+0x1211
bordbk100N.dll!POSTEDHOOKPROC+0x4f2
bordbk100N.dll!POSTEDHOOKPROC+0x6d5
bordbk100N.dll!POSTEDHOOKPROC+0x261
bordbk100N.dll!isDbkLoggingOn$qv+0x5d43
bordbk100N.dll!isDbkLoggingOn$qv+0x5ff8
bordbk100N.dll!isDbkLoggingOn$qv+0x60d5
bordbk100N.dll!isDbkLoggingOn$qv+0x6d69
dbkdebugide100.bpl!Debug+0x33
coreide100.bpl!Callstac+0x85
coreide100.bpl!Callstac+0x38
coreide100.bpl!Callstac+0x5a
coreide100.bpl!Callstac+0xa8

Inspecting the stack multiple times one can see that it
seems to be stuck.

ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]

ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]

ntoskrnl.exe!ZwAlertThread+0x28
hal.dll!ExReleaseFastMutex+0x1a
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]

As you can see most of the stack is always the same and
only the functions above
'bordbk100N.dll!POSTEDHOOKPROC+0x10af' change.

Inspecting the BDS-process with "Process Monitor" shows
that there is no file or registry activity at all.

Experiments:
============
I made some experiments to narrow the causes for this
behaviour.

1. I almost completely removed the code from the source
where I observed the freeze. Only a few headers were left.
No precompiled headers were used. Effect: none

2. I turned off precompiled headers for the project.
Effect: none

3. I made a release build of all targets used in the
project. Effect: none

4. I manually deleted all TDS files (btw: why are there
any after a release build?). Effect: none

5. I reduced the complexity of the function called to
almost zero: void func(void) { asm { db 0xcc; } }. Effect:
none

6. I called the function in question at another time of
the program: freeze disappeared. *Note*: The very same
function-call-stack-inspection one time freezes the IDE,
and in the other call context, everything is ok.

Conclusions:
============
I think it is safe to assume, that there is a bug in the
de{*word*81} when inspecting stacks.


Resolution:
===========
So what is to do next? I have spent many hours to narrow
down the possible causes for this problem - but without
the sources for the de{*word*81}, I think there is nothing
reasonable I could do more.

So would please anyone at Codegear look into this? I
promise to buy BDS2007 if you fix this bug. :)

Thanks a bundle.

Best Regards
Eike Petersen
Cologne, Germany

 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Hi. Again.
I couldn't keep myself from investigating further and found something interesting.
It was already very unlikely that the function and source where I stumbled into
this problem had anything to do with the problem, so I tried to "climb" up the
stack manually.
The situation in which this occurs and code being executed is like the following:
- A button/or menu is pressed in a form
- The button has an assigned "TAction"
- The action's "OnExecuteAction"-event is called
- The associated action has an id assigned to its tag property
- For this id the program finds a command factory
- The factory constructs a "command" and the program executes it by calling
"Execute"
After hitting a breakpoint on the concrete commands constructor and inspecting
the stack, the IDE freezes.
We use the DX-Bar components, so I tried to set a breakpoint on the
OnClick-handler. When this breakpoint hits, the call stack is accessible and
looks like this:
:00000001
:01023148 dxBarC10.@Dxbar@TdxBarItemControl@BeginGroupChanged$qqrv
:01024b20 dxBarC10.@Dxbar@TdxBarButtonControl@ControlUnclick$qqro
I don't understand the :00000001 at the top - maybe it has todo with the
problem. But let's go on.
If I now press F9 and try to inspect the stack when the command-constructor
breakpoint gets hit, the IDE freezes again. *BUT*, if I step through the
CPU-window first for some time and follow the code I finally arrive at the
command-constructor breakpoint and - hold your breath - everything is ok!
After that I can remove the DX-Bar breakpoint and when I hit my breakpoint
everything is still ok. Inspecting the stack or looking at the local variables
is no problem anymore. The stack looks like this then:
Quote
:02349104 ExportDataCommand::ExportDataCommand(this=:01FEF4A8, techComponentModel=:04734858)
:023C205B FileCommandsFactory::MakeCommand(this=:04C592DC, id=1181)
:011f29d7 nxUI_VCL.@Nx@ActionCommandRouter@OnExecuteAction$qqrp14System@TObject + 0x4f
:51f5ff02 rtl100.@Classes@TBasicAction@Execute$qqrv + 0x12
:01023446 ; Oledlg
:00000001
:01023148 dxBarC10.@Dxbar@TdxBarItemControl@BeginGroupChanged$qqrv
:01024b5d dxBarC10.@Dxbar@TdxBarButtonControl@ControlUnclick$qqro + 0x3d
The two addresses above the dxBarC10-calls look very suspicious to me - but I
have seen the IDE showing and doing weird things, so what do I know...
Astonishing - isn't it?
Regards
Eike Petersen
 

{smallsort}

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

I would do that, if I could. But the problem doesn't show up in an isolated test
environment. The program uses about 40 DLLs and BPLs (many of them commercial)
and consists of hundreds of sources. I cannot send them to Codegear :)
I'm still trying to isolate the problem. Reporting the problem like this doesn't
seem to make much sense to me, since it is unlikely they will be able to
reproduce it...
Regards
Eike
Pete Fraser wrote:
Quote
Please add a report on this at qc.codegear.com.
CodeGear don't officially look in these ngs.
If you can include a simple project with steps to show the
problem it is even more likely to get fixed.
(That is if it has not already been fixed)
Thanks, Pete
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Eike Petersen wrote:
Quote
Hi.

There were several other threads about this topic, but I still see no
resolution to this problem, and I'm very worried that this bug will
still be present in BCB2007 - so here we go again.

Eike,
I have been running into the same problem for over a year now. I had a
similarly consistent failure that I reported to QC as a private report
last June. I attached my complete project so Borland/CodeGear could find
and fix the bug.
Report #: 30653 Status: Closed
De{*word*81} causes IDE to lockup
qc.codegear.com/wc/qcmain.aspx
I have deleted my project files from the report and marked it public now
that it has been closed.
The problem was identified last September, and fixed in February. The
fix has not been released yet.
I am hopeful that it will be fixed in the soon to be released BCB2007
version, but I did not take part in the field test (so I can say that
;-)), so I can't say for certain that it has been addressed.
You may want to delay further testing until the new version is released.
Dennis Cote
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

I'm glad to hear that. So at least there is hope.
Thanks Dennis.
Regards
Eike Petersen
Dennis Cote wrote:
Quote
Eike Petersen wrote:
>Hi.
>
>There were several other threads about this topic, but I still see no
>resolution to this problem, and I'm very worried that this bug will
>still be present in BCB2007 - so here we go again.
>

Eike,

I have been running into the same problem for over a year now. I had a
similarly consistent failure that I reported to QC as a private report
last June. I attached my complete project so Borland/CodeGear could find
and fix the bug.

Report #: 30653 Status: Closed
De{*word*81} causes IDE to lockup
qc.codegear.com/wc/qcmain.aspx

I have deleted my project files from the report and marked it public now
that it has been closed.

The problem was identified last September, and fixed in February. The
fix has not been released yet.

I am hopeful that it will be fixed in the soon to be released BCB2007
version, but I did not take part in the field test (so I can say that
;-)), so I can't say for certain that it has been addressed.

You may want to delay further testing until the new version is released.

Dennis Cote


 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Hmm. After reading the description of your entry, I'm not sure this is the same
bug. In my case the CPU goes immediately up to 100% cpu use when accessing the
call stack. Also the circumstances under which the freeze appears seem to be
different.
You must have lost many hairs about this problem, considering how much effort it
took you, just to bring Borland to look into it...
Regards
Eike
Eike Petersen wrote:
Quote

I'm glad to hear that. So at least there is hope.

Thanks Dennis.

Regards
Eike Petersen

 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

In article < XXXX@XXXXX.COM >,
Eike Petersen < XXXX@XXXXX.COM >wrote:
Quote
So what is to do next? I have spent many hours to narrow down the possible
causes for this problem - but without the sources for the de{*word*81}, I think
there is nothing reasonable I could do more.
So would please anyone at Codegear look into this?
I'd like to take a look. You can contact me directly by email.
Quote
I promise to buy BDS2007 if you fix this bug. :)
I'm hoping that it has already been fixed, but if it hasn't I'll push
hard to see that it is.
--
-David Dean
CodeGear C++ QA Engineer
<blogs.codegear.com/ddean/>
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Eike Petersen wrote:
Quote
Hmm. After reading the description of your entry, I'm not sure this is
the same bug. In my case the CPU goes immediately up to 100% cpu use
when accessing the call stack. Also the circumstances under which the
freeze appears seem to be different.

Eike,
You may be correct, yours could be a different bug.
I have had to work without the local variables pane for a long time, but
I have still had many IDE hangs while using the de{*word*81}. Many seem to
be related to a bad interaction between codeguard and the memory manager
in multithreaded apps. I have recently given up on codeguard because of
these issues. Others are unknown, but may in fact be the problem you
have identified.
Quote
You must have lost many hairs about this problem, considering how much
effort it took you, just to bring Borland to look into it...

Yes I did, and the hairs that are left have all turned grey while
waiting for the fix to be released. :-)
You should definitely take David Dean up on his offer to look into your
problem. He is very likely to get someone to look at it if he can
reproduce it. He might even get you a field test version to try
yourself, but then you won't be able to talk about your tests or the
results any further.
Dennis Cote
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

On Wed, 23 May 2007 12:42:06 +0200, Eike Petersen
< XXXX@XXXXX.COM >wrote:
Quote
Inspecting the BDS process with SysInternals Process Explorer you can see that
it uses 100% cpu resources, all of it in the BDS main thread. The call stack for
this thread looks like this:
if you want deeper analysis of what bds ide does when it hangs you may
want to use madExcept (which is superior to jcl built-in). either
install madExceptIde package or build and install any other package
with madExcept enabled and you not only will be able to see detailed
report when exception within ide happens but also see what's going on
behind the scenes when ide stops responding using wonderful tool
madTraceProcess. it will show you all sort of weird things bds does
Quote
Conclusions:
============
I think it is safe to assume, that there is a bug in the de{*word*81} when
inspecting stacks.
oh yes definitely there are. while your observations look very
familiar to me I'd like to add that in some cases instead of{*word*154}
the whole bds ide simply vanishes completely from the processes when I
try to debug dcom server written with bcb2006. so I'd rather say that
bds de{*word*81} is practically unusable
--
Vladimir Ulchenko aka vavan
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Turn off all the watch windows and it works great!!!!
"Eike Petersen" < XXXX@XXXXX.COM >wrote in message
Quote
Hi.

There were several other threads about this topic, but I still see no
resolution to this problem, and I'm very worried that this bug will still
be present in BCB2007 - so here we go again.

First some information:
=======================
- BDS2006 with all Updates and all hotfixes applied
- Tested on several systems (Windows XP (32bit), SP2, all hotfixes)
- All systems are properly maintained with very few applications running

Symptoms:
=========
Arriving on a breakpoint and inspecting the call-stack freezes the
de{*word*81} and the IDE completely. The same effect happens when trying to
open the "local variables". If one of those debug windows is opened in the
debug layout the IDE /de{*word*81} freezes when it hits the breakpoint. This
effect is reproducible and happens every time when I try to access the
call stack. I used always the same source and function in this tests, but
I have several sources where this effect occurs.

Inspecting the BDS process with SysInternals Process Explorer you can see
that it uses 100% cpu resources, all of it in the BDS main thread. The
call stack for this thread looks like this:

ntoskrnl.exe+0x5909
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
bordbk100N.dll!POSTEDHOOKPROC+0x1a83
bordbk100N.dll!POSTEDHOOKPROC+0x1e85
bordbk100N.dll!POSTEDHOOKPROC+0x1f4a
bordbk100N.dll!POSTEDHOOKPROC+0x1211
bordbk100N.dll!POSTEDHOOKPROC+0x4f2
bordbk100N.dll!POSTEDHOOKPROC+0x6d5
bordbk100N.dll!POSTEDHOOKPROC+0x261
bordbk100N.dll!isDbkLoggingOn$qv+0x5d43
bordbk100N.dll!isDbkLoggingOn$qv+0x5ff8
bordbk100N.dll!isDbkLoggingOn$qv+0x60d5
bordbk100N.dll!isDbkLoggingOn$qv+0x6d69
dbkdebugide100.bpl!Debug+0x33
coreide100.bpl!Callstac+0x85
coreide100.bpl!Callstac+0x38
coreide100.bpl!Callstac+0x5a
coreide100.bpl!Callstac+0xa8

Inspecting the stack multiple times one can see that it seems to be stuck.

ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]

ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]

ntoskrnl.exe!ZwAlertThread+0x28
hal.dll!ExReleaseFastMutex+0x1a
ntoskrnl.exe!ZwSetSystemInformation+0x23
ntdll.dll!KiFastSystemCallRet
kernel32.dll!VirtualAlloc+0x18
bordbk100N.dll!POSTEDHOOKPROC+0x10af
[... same as above...]

As you can see most of the stack is always the same and only the functions
above 'bordbk100N.dll!POSTEDHOOKPROC+0x10af' change.

Inspecting the BDS-process with "Process Monitor" shows that there is no
file or registry activity at all.

Experiments:
============
I made some experiments to narrow the causes for this behaviour.

1. I almost completely removed the code from the source where I observed
the freeze. Only a few headers were left. No precompiled headers were
used. Effect: none

2. I turned off precompiled headers for the project. Effect: none

3. I made a release build of all targets used in the project. Effect: none

4. I manually deleted all TDS files (btw: why are there any after a
release build?). Effect: none

5. I reduced the complexity of the function called to almost zero: void
func(void) { asm { db 0xcc; } }. Effect: none

6. I called the function in question at another time of the program:
freeze disappeared. *Note*: The very same function-call-stack-inspection
one time freezes the IDE, and in the other call context, everything is ok.

Conclusions:
============
I think it is safe to assume, that there is a bug in the de{*word*81} when
inspecting stacks.


Resolution:
===========
So what is to do next? I have spent many hours to narrow down the possible
causes for this problem - but without the sources for the de{*word*81}, I
think there is nothing reasonable I could do more.

So would please anyone at Codegear look into this? I promise to buy
BDS2007 if you fix this bug. :)

Thanks a bundle.

Best Regards
Eike Petersen
Cologne, Germany

 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Did you even read my posting? Turning off the watch windows doesn't help at all.
Regards
Eike Petersen
ActuaryOne wrote:
Quote
Turn off all the watch windows and it works great!!!!
"Eike Petersen" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

I was having a de{*word*81} problem that seems to be related to an old CG32.DLL
library in the Windows/System32 directory (Storage overlays, Strings
changing values etc. ). I still have problems now that I deleted the older
CG32.DLL library. BDS 2006 goes into a loop consuming large quantitys of
CPU. I think the next step for me is to turn off all Codeguard options.
"Eike Petersen" < XXXX@XXXXX.COM >wrote in message
Quote
Did you even read my posting? Turning off the watch windows doesn't help
at all.

Regards
Eike Petersen

ActuaryOne wrote:
>Turn off all the watch windows and it works great!!!!
>"Eike Petersen" < XXXX@XXXXX.COM >wrote in message
>news: XXXX@XXXXX.COM ...

 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Has anyone had the chance to determine if the de{*word*81} is behaving better in
BDS2007?
I too am struggling with the BDS2006 de{*word*81} and will gladly upgrade if I
know it'll help.
 

Re:BDS 2006 "De{*word*81} Freeze / Hang" Analysis

Back on May 23 of this year there was a discussion in this group concerning
the BDS 2006 De{*word*81} freezing and{*word*154}. There were some remarks that
stated some of the issues "might" (notice the quotes) be resolved in the new
BDS2007.
Has anyone had the chance to determine if the de{*word*81} got its Ritalin shot
and is now behaving better in BDS2007?
I too am struggling with the BDS2006 de{*word*81} and will gladly upgrade if I
know it'll help.