Is this normal?
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
Odds are you have runaway threads, which cause a system to appear locked up.
-
Well, to review, you're not a programmer, you're writing code involving threads, on an out of data compiler ( although, to be fair, not by much ), and it sounds like the computer you've been given is a piece of rubbish. Who do you work for ?
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
Christian Graus wrote:
Who do you work for ?
I realize this is old, but I was hoping he would say "Telstra" :laugh:
"The activity of 'debugging', or removing bugs from a program, ends when people get tired of doing it, not when the bugs are removed." - "Datamation", January 15, 1984
-
PaulowniaK wrote:
Granted I'm doing dodgy things with threads when I don't really understand them
Oh dear :sigh: Threads and the unexperienced are a recipe for disaster.
Norm .net wrote:
Oh dear Sigh Threads and the unexperienced are a recipe for disaster.
That's... very comforting to know... ... ... X|
-
Thanks for the info.:thumbsup: It's quite hard, but I'll try reading it.
-
Odds are you have runaway threads, which cause a system to appear locked up.
Joe Woodbury wrote:
Odds are you have runaway threads, which cause a system to appear locked up.
Most likely...:thumbsup:
-
Norm .net wrote:
Oh dear Sigh Threads and the unexperienced are a recipe for disaster.
That's... very comforting to know... ... ... X|
You know, you wouldn't do open heart surgery without training and experience, the same goes with software engineering.
-
You know, you wouldn't do open heart surgery without training and experience, the same goes with software engineering.
Norm .net wrote:
You know, you wouldn't do open heart surgery without training and experience
True... but it's not so common that you kill someone by writing bad code... I'm sure you can (f-ing up the software used in air traffic control, say) but in my case, the worst that is going to happen is that some ionized molecules are going to go to ionized molecule heaven.
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
There are two usual causes to freezing machines: 1) Memory leaks: Watch your memory usage in Task Manager. Does it rise faster than you can explain? Then you very likely forgot to free the memory of some objects which you create in a loop. 2) Never ending loops: Watch you CPU time in Task Manager. Does it reach 100% before the machine freezes? Then very likely a break condition is never reached (i.e. you loop over a list, but forget to increment the index). As you are unexperienced, only a debugger can save you.
This statement is false.
-
Norm .net wrote:
You know, you wouldn't do open heart surgery without training and experience
True... but it's not so common that you kill someone by writing bad code... I'm sure you can (f-ing up the software used in air traffic control, say) but in my case, the worst that is going to happen is that some ionized molecules are going to go to ionized molecule heaven.
That was a brilliant response to the inaccurate comparison. :thumbsup:
-
PaulowniaK wrote:
I don't call myself a programmer, nor a software developer.
Nor do I. Stop what you are doing and get a different job. And yes, you can quite easialy lock the machine with threads it all depends on priority, have yiou been messing with thread prioirity too?
Morality is indistinguishable from social proscription
You will never learn, unless you try. Succeed or fail, don't give up. Assuming of course you actually like what you're doing/learning. Never listen to another's notion that you "can't" or "shouldn't". Yes, malformed threads can cause the behavior you are experiencing, and they will extend to the end-user unless corrected.
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
If you're not a programmer you might want to convince someone to let you program in something other (i.e. easier, or more forgiving) than C++.
-
Norm .net wrote:
You know, you wouldn't do open heart surgery without training and experience
True... but it's not so common that you kill someone by writing bad code... I'm sure you can (f-ing up the software used in air traffic control, say) but in my case, the worst that is going to happen is that some ionized molecules are going to go to ionized molecule heaven.
Actually, you _can_ kill people with bad code. You should subscribe to comp.risks. It is replete with stories about how software causes death or destruction.
-
If you're not a programmer you might want to convince someone to let you program in something other (i.e. easier, or more forgiving) than C++.
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
It can. Depends a lot on what you're doing and in which functions. The machines that windows runs on have gotten a lot better over time, but the old Win32 GUI thread bug is still there -- it stops by my PC for a scotch and to reminisce every now and then. I don't usually have to reboot to exorcise it anymore like the old days -- logging out and back in is usally as bad as things get, and rarely that anymore. Just part of the (un)fun of programming sometimes. Now if the mosue stops working, that's a differnet matter.
patbob
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
"Not a Programmer" + "C++" + "Threads" = BOOM ! :-D Yes, that would be expected, at least to some degree. It's a little suprising the whole machine locked up rather than just your app, but you are working in C++ where you can shoot yourself in the foot in many different ways so it is possible to lock up the entire PC (deadlocking the kernel somehow, for instance). Good luck, you're going to need it :) http://burks.bton.ac.uk/burks/language/shoot.htm[^]
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
-
I don't call myself a programmer, nor a software developer. I'm just doing a job that I can sort of do... on a good day... Anyway, I'm writing a small test app for a DLL I've been told to develop in C++ in VS2005. My whole PC froze on me twice in about 2 hours. The latest incident was so bad I had to resort to the "big red button" approach, i.e. kill the power. Actually, this isn't the first time this happened to me. Granted I'm doing dodgy things with threads when I don't really understand them, but it shouldn't keep locking me out like this, should it?
Hi, I have a suspicion about your problem: The DLL you've mentioned: does it in any way communicate with a device? What you said about those ionized molecules supports this. When there's a hardware driver that has been written for internal use, and a DLL that provides an API for it, also meant for internal use, chances are high that these are not as robust as drivers and DLLs meant for the consumer market. That means that it is often easy to write code using such an API or driver that crashes the operating system's kernel (that's the very core of the operating system). It does not mean that the driver and DLL are actually badly designed or written. It only means that they're not supposed to be used by a great number of developers out-of-house. My first guess for a solution: check what you've been writing against the documentation / source code / comments, whatever you have. Second guess: you've actually broken your own code via some flaw in your use of threads that leads to some kind of unexpected behavior that, via the DLL and the driver, crashes the kernel. So, unless the first approach was sufficient, find out whether the behavior you've encountered is reproducible without multiple threads. Cheers from Vienna, The Continent
-
Hi, I have a suspicion about your problem: The DLL you've mentioned: does it in any way communicate with a device? What you said about those ionized molecules supports this. When there's a hardware driver that has been written for internal use, and a DLL that provides an API for it, also meant for internal use, chances are high that these are not as robust as drivers and DLLs meant for the consumer market. That means that it is often easy to write code using such an API or driver that crashes the operating system's kernel (that's the very core of the operating system). It does not mean that the driver and DLL are actually badly designed or written. It only means that they're not supposed to be used by a great number of developers out-of-house. My first guess for a solution: check what you've been writing against the documentation / source code / comments, whatever you have. Second guess: you've actually broken your own code via some flaw in your use of threads that leads to some kind of unexpected behavior that, via the DLL and the driver, crashes the kernel. So, unless the first approach was sufficient, find out whether the behavior you've encountered is reproducible without multiple threads. Cheers from Vienna, The Continent
Member 4569938 wrote:
What you said about those ionized molecules supports this.
Indeed! I do have a prototype device connected to my PC via a second network card and cross cable. I was wondering about this because it is very "prototype" and it keeps dying on me on its own accord too. At the time I got locked out of my machine, I wasn't using the device, but I think it was switched on. I had been using it previously too. So it could well be that. Sadly, it doesn't come with much documentation so I have to keep walking the tight rope. Thanks for the suggestion anyway, I shall be a bit more careful about what I tell this device to do. :thumbsup: