what would cause a program to crash on a specific hardware set and not others?

yet another infuriating problem of mine.

so this time, my application runs beautifully on every single computer i've tried it on, lots of different brands, speeds, single/multi processor, varying amounts of RAM, etc.

except, it doesn't run on the tool computer. the one i really need it to run on X(

it starts initialization, and then just closes itself. the only error message i could tease out of the thing was "abnormal program termination".

is it perhaps running out of stack memory or something? i allocate pretty much everything off the heap, and the machine has 512MB ram, and my app only takes 12MB.

this is really horribly disparaging. any ideas on what it might be or how to diagnose would be greatly appreciated.

Without code we can only guess. You're overrunning a buffer perhaps, or writing to uninitialized memory, or deleting a pointer twice, or slicing an object, or returning the address of a local from a function, etc. Could be any number of things that work (or don't crash) on some systems, but do on others.

well, that's a list of things to look for, so that's quite helpful!

if push comes to shove, i'll post it up. i've isolated the problem to a particular object, but it has a few thousand lines to comb through :\

double post

try running the program through gdb (or your favourite debugger) and see how it crashes?

Quote:

---

Originally Posted by m37h0d

i've isolated the problem to a particular object, but it has a few thousand lines to comb through :\

---

:eek:

A few thousand? Sounds like a refactoring may be in order.

If you want, you can snatch the crash dump when the app crashes and analyze it.
For Windows, you would need WinDbg (the crash dump will appear in your temp directory, so snatch it before you decide to send the error or not, because it deletes it afterwards).
Analyzing it will probably find the root of the problem.

Quote:

---

Originally Posted by medievalelks

:eek:

A few thousand? Sounds like a refactoring may be in order.

---

it's for a USB NIR spectrometer. there's a lot it has to do. that "few thousand" was for all the code i'd have to include to give the appropriate context; both the abstract spectrometer base class, and the derived one(s) for this particular make and model.

that and i tend to leave curly braces on lines of their own

Quote:

---

Originally Posted by Elysia

If you want, you can snatch the crash dump when the app crashes and analyze it.
For Windows, you would need WinDbg (the crash dump will appear in your temp directory, so snatch it before you decide to send the error or not, because it deletes it afterwards).
Analyzing it will probably find the root of the problem.

---

another weird thing, i never get that send/don't send dialog. it just dies without complaining. i only got the "abnormal program termination" dialog after i had modified the initialization code to include calls to show message dialogs indicating where it was in the process (not a great way to do it i know, but it was quick)

Well, that could indicate that you did something wrong inside the C/C++ framework and it called abort() and terminated the program.
In that case, you've got 2 options:

- Debugging
- Logging

If you can get install a debugger or use a remote debugger - that's great.
Otherwise you can include logging in your app to try to find the root of the problem.

If your program just disappears, that's usually stack overflow. Check your recursion.

excellent. thank you. that is consistent with the behavior of the code that seems to be causing the problem.