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

This is a discussion on what would cause a program to crash on a specific hardware set and not others? within the C++ Programming forums, part of the General Programming Boards category; yet another infuriating problem of mine. so this time, my application runs beautifully on every single computer i've tried it ...

  1. #1
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839

    Angry 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.

  2. #2
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    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.

  3. #3
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    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 :\

  4. #4
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    double post

  5. #5
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    try running the program through gdb (or your favourite debugger) and see how it crashes?

  6. #6
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by m37h0d View Post
    i've isolated the problem to a particular object, but it has a few thousand lines to comb through :\


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

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    Quote Originally Posted by medievalelks View Post


    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

  9. #9
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    Quote Originally Posted by Elysia View Post
    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)

  10. #10
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    If your program just disappears, that's usually stack overflow. Check your recursion.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  12. #12
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    excellent. thank you. that is consistent with the behavior of the code that seems to be causing the problem.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21