Is this normal?
-
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: