| Author |
 Topic  |
|
|
mellis67
New Member
USA
7 Posts |
 Posted - Aug 25 2004 : 10:23:53 PM
|
I recently had a harddrive failure and had to reinstall my OS, development environments, etc. Luckily I had a recent backup. My previous OS was Windows 2000. I had VAX version 10.0.1242.0 installed in that system with VS6.0 SP6. No problem whatsoever. Always worked perfectly.
Ok, So I reinstalled using WindowsXP Pro as the OS (1st Difference). I reinstalled OfficeXP and all of my other applications. Installed VS6.0, VS6.0SP6, VS.NET2003 Enterprise Edition, and reinstalled my last version of VAX I had downloaded (10.0.1242.0). XP has had all of the windows updates except SP2 (via Windows Update functionality in XP)
Now, I am having weird crashes during completion. At first, I thought it may be related to a hardware problem or not having installed something right. Finally I was able to narrow it down and reproduce it. It happens during completion (not all the time though--if I do something else before trying to reproduce the crash, it may or may not occurr).
I have tried deleting my ncb file, clearing the history and cache, and forcing a rebuild of the symbol data and many different combinations of configurations in VAX. After restarting the IDE, I open the project I had been working on before my harddrive crash (never had a problem with VAX before in this project) and I wait for the "parsing..."/"Sorting" annunciations in the status bar of the IDE to cease and the "Ready" annunciation is displayed for at least 20 seconds.
I goto a message handler in my code and when I type the 1st letter I get the popup box that looks like this.
Most times it will crash about 3 seconds after the popup listbox shown above pops up.
If I change the options to not have the listbox there, it will crash when I type the -> after the variable pTVDispInfo. I also just tried typing the variable name, once it is recognized and shows up in the top of the edit window (drop down combo boxes with yellow arrows), it crashes about 3 seconds after it is recognized. By crashing, I mean the IDE just disappears. If I don't type pTVDispInfo, but instead type CWnd::, the popup of the members will pop up, then 3 seconds later it crashes. If I go to the previous function and type CWnd::, it works and doesn't crash. If I immediately proceed to the same point in the TVDISPINFO message handler and type CWnd::, it works (CWnd:: doesn't crash it then). However, if I immediately type pTVDispInfo then -> it crashes after about 3 seconds. I tried moving the message handler to another spot in the file with no success. The type TV_DISPINFO is very heavily nested typedef controlled by macros. I have installed the PlatformSDK feb 2003 version. The commctrl.h file in the platformSDK include is where the type is finally defined after going through a bunch of typedefs and macro ifdef's. I don't know if that has anything to do with it or not, but the crash behavior appears to be related to the embedded typedef's for TV_DISPINFO and may be indicative of a bug related to nested macro'd typedef'd types. Or maybe it just has something to do with my configuration. The only other add-in I have is a codejock add-in. It basically has a special classwizard for the codejock MFC library. And I had no problems before with this configuration.
Here is my "about" VAX dialog (after I have installed the latest VAX version--same problem though):
Any help in this would be greatly appreciated. I will send you the va.log file if you like. I just can't go back to the old intellisense after using the otherwise wonderful product. I can run VS6.0 as a debugee of VS.NET debugger and provide further information if you need it.
|
Edited by - mellis67 on Aug 26 2004 04:41:30 AM |
|
|
mellis67
New Member
USA
7 Posts |
Posted - Aug 26 2004 : 02:33:54 AM
|
I have done some more testing by debugging VS6.0 when it crashes visa via VS.NET 2003.
Here is the relevant data:
Unhandled exception at 0x1ed535f5 in msdev.exe: 0xC0000005: Access violation writing location 0x03270ffc.
Debug Trace:
The thread 'Win32 Thread' (0xf7c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xc38) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x694) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xcb4) has exited with code 1 (0x1).
First-chance exception at 0x1ed535f3 in msdev.exe: 0xC00000FD: Stack overflow.
The thread 'Win32 Thread' (0xcd8) has exited with code 1 (0x1).
First-chance exception at 0x1ed535f5 in msdev.exe: 0xC0000005: Access violation writing location 0x03270ffc.
Unhandled exception at 0x1ed535f5 in msdev.exe: 0xC0000005: Access violation writing location 0x03270ffc.
First-chance exception at 0x1ed535f5 in msdev.exe: 0xC0000005: Access violation writing location 0x03270ffc.
Unhandled exception at 0x1ed535f5 in msdev.exe: 0xC0000005: Access violation writing location 0x03270ffc.
Call Stack:
> VA_X.dll!1ed535f5()
VA_X.dll!1ed53a32()
VA_X.dll!1ed5109a()
VA_X.dll!1ed53f1a()
VA_X.dll!1ed5109a()
VA_X.dll!1ed53f1a()
VA_X.dll!1ed5109a()
VA_X.dll!1ee4cf3e()
kernel32.dll!77e76111()
kernel32.dll!77e76111()
VA_X.dll!1edc503f()
VA_X.dll!1ed0741a()
VA_X.dll!1ed940a3()
VA_X.dll!1ed9415a()
VA_X.dll!1ed9415a()
VA_X.dll!1ed9415a()
VA_X.dll!1ed9415a()
VA_X.dll!1ed9415a()
VA_X.dll!1ed9415a()
VA_X.dll!1ed9415a()
**SNIP-->About 1000 more of VA_X.dll!1ed9415a() calls
It looks as if we have a recursive call here that overflows the stack and causes a cascading failure. Maybe you guys can fix it in a new release, or maybe you can just give us some pointers on how to work around the problem by avoiding whatever is calling that recursive call.
Waiting patiently,
Marty |
 |
|
|
Cezariusz
Tomato Guru
Poland
244 Posts |
Posted - Aug 26 2004 : 03:27:28 AM
|
Marty,
You will have to post image somewhere on the web, or send it to [email protected] with subject TOPIC_ID=2797. We cannot see images on your c:\\ drive. |
Cezariusz Marek
https://midicat.net/ |
|
|
|
mellis67
New Member
USA
7 Posts |
Posted - Aug 26 2004 : 04:17:38 AM
|
Oh thanks, I wasn't sure that would work. Unfortunately it showed fine in the preview and shows fine in my view of the forum. A whole lot of good that does. I guess I thought the forum code would post my gif to the server somewhere. I will fix it in a little bit.
|
|
|
|
mellis67
New Member
USA
7 Posts |
Posted - Aug 26 2004 : 04:46:12 AM
|
Ok, now those images should show up. If you don't see an image or a URL, let me know.
|
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Aug 26 2004 : 04:59:05 AM
|
Is this the same as topic 2743?
Support said that they thought they had a fix for the bug in the other topic in the next version, but they seemed not entirely sure. Your observation about recursion is a good clue. Maybe support can tell us whether they believe your bug is the one they already have a fix for. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
mellis67
New Member
USA
7 Posts |
Posted - Aug 26 2004 : 11:50:25 AM
|
I DO think this is a similiar if not the exact same bug as topic topic 2743.
I tried all of the possible work-arounds as discussed in that topic to no success. I think that the bug is confusing because there is a delay between the initiation of the crash and the crash (people think its after the listbox, or after they type this or that, when in fact the stack is filling up and it just appears to crash when they do those things--it has something to do with the code that finds the symbol in its cache/tmp files). I think support is wrong in saying it is related to default intellisense becoming active (hence the delay they say). I believe the delay is the stack filling up with recursive calls. It may be as simple as limiting the recursion or catching more exceptions in their code--specifically stack overflow. Since VAX is an add-in I don't think they can affect the stack size for the application (MSDEV). If I had this problem, and it was an exe--, I would double or triple the stack size visa via the compiler/linker. If that didn't change the frequency of the problem, then I would very carefully and defensively analyze the code in any recursive calls in the application.
I think this problem will appear randomly depending on how much stack space people are using in their particular instance of Visual Studio.NET or VS6. For me, this particular case allowed me to inevitably cause the crash. It was extremely repeatable. How it acts depending on what order I do things (i.e., when it will not crash) also gives good evidence of where the problem is.
I thought that giving clues in Visual Studio 6 would be extremely useful because of the similiar nature as topic 2743.
I love WholeTomato and VAX. It is such a well designed and conceived application, I just hope I can be a little help in finding this problem so I can get back to using it with confidence. I am still using it now, but I turn it off in those situations where it causes a crash--it really makes me realize how much I depend on VA.
|
|
|
|
mellis67
New Member
USA
7 Posts |
Posted - Aug 26 2004 : 12:10:46 PM
|
BTW, It appears as if this recursive call is coming from a worker thread. If that is a VAX thread function, then they should be able to control the stack size when they start the thread.
|
|
|
|
mellis67
New Member
USA
7 Posts |
Posted - Aug 31 2004 : 8:36:22 PM
|
WORK-AROUND FIX!!!
I had turned off my completion functionality, but decided I had had enough of not being able to use VAX the way I wanted to and decided to try to find a work-around. I uninstalled and reinstalled to no success. Then I started messing with the VAX options again. I finally narrowed down the config that contributes to the crash to this:
None of the other settings had an effect (except for turning off completion). If I enable the "Parse all files when opening a project" (the default setting on my machine after installation), the system would always crash if I immediately executed the test point I indicated in the first post to this topic.
Without it enabled, it works fine--so far. At least the point of failure I had before has disappeared. Hope this helps somebody and WT support in fixing the problem.
Make sure you "Rebuild" and "Clear" on this option dialog after changing the "Parse all Files..." option.
Marty |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Sep 01 2004 : 11:40:38 AM
|
Marty:
We added you to a private beta for VA X 10.1. The newer version might have the [real] fix you need.
Check the forum for the software. Tell us what you discover. |
|
|
| |
Topic |
|
Topic Locked
