5

I have a c++ dll which I need to debug. Due to the circumstances in which I am using the dll, I am unable to debug it via the calling application.

So, I created a try -catch, where the catch writes the exception to a file.

The line which needs to be debugged involves imported classes from a 3rd party dll, so I have no way of knowing what type of exception it is. When I tried catch(exception e), no message was written to the file. So I tried catch(...), which did trigger something:

using std::exception::what, the only thing that got written to the file was "1". using std::exception::exception, the file received the following code : "0579EF90".

Is there any way for me to retrieve meaningful info about the exception that was thrown?

TIA

CG

user228058
  • 465
  • 1
  • 7
  • 22
  • Review the license you obtained to use this DLL to see what kind of support you can count on to help you exercise your license rights. If you have no such license then you'll need to get one. – Hans Passant Jan 12 '10 at 16:38
  • Operating System - Windows XP IDE - Visual Studio 2005 – user228058 Jan 12 '10 at 16:55
  • `catch(...)` can't call `std::exception::what`, and `std::exception::exception` is a constructor, that doesn't have anything to do with "codes". The information in your question is wrong and needs to be rewritten. Also, you should catch `std::exception` by reference. – Mooing Duck Jun 08 '15 at 23:54

5 Answers5

8

If you don't use catch(KnownExceptionType ex) and use your knwoledge about KnownExceptionType to extract info, no you can't.

When you catch with catch(...) you are pretty much lost, you know that you handled an exception but there is no type information there, there is little you can do.

You are in the worse case, an exception coming out from a library, you have no info on the exception, even if you had headers for the lib, that exception type doesn't need to be defined there.

Arkaitz Jimenez
  • 22,500
  • 11
  • 75
  • 105
  • thanks, would you have any alternative suggestion for me at this point? – user228058 Jan 12 '10 at 16:33
  • Forget about the info you can extract fromt he exception at the catch point, maybe you can use a debugger and find the problem before the exception gets triggered. – Arkaitz Jimenez Jan 12 '10 at 16:40
  • what do you mean by 'use a debugger'? Do you know of a way that I can debug a C++ dll without the calling application? – user228058 Jan 12 '10 at 16:54
  • 4
    Why is it you cannot use the calling application - you haven't made this clear. –  Jan 12 '10 at 16:58
  • @user228058; If the debugger can't _launch_ the code, you can stil llaunch it manually and have the debugger _attach_ to the program. – Mooing Duck Jun 08 '15 at 23:55
4

If I understand you correctly, you've already narrowed down the source of the issue to a specific call to a 3rd party library, but you're not allowed to debug the application live (do I want to ask why?), and your question is "how can I debug the exception without any knowledge of what the exception is"

The answer is, you can't. As you observed, you can blindly guess and hope to catch the right thing. You can also catch(...), but that will tell you exactly nothing. If you could debug live, you could set the debugger to break when the exception is thrown and see what is going on there.

I think the right answer though is to contact the 3rd party library you've narrowed down the source of the issue to and ask them. It is very, very bad form to throw an exception and allow it to propogate across module boundries. It makes me suspect that it's a Windows SEH exception for a null pointer deref or something, and you're compiling in such a way that catch(...) catches those.

Terry Mahaffey
  • 11,775
  • 1
  • 35
  • 44
3

maybe try catching std::exception & e

  1. std::cout << e.what() << endl;
  2. see if you can cast it to std::logic_error, and std::runtime_error - that should give you some clue what you're dealing with
George Godik
  • 1,716
  • 1
  • 14
  • 19
1

Firstly, you should always catch exceptions by const reference, in other words:

catch( const std::exception & ex ) {
  ...
}

Not doing so means that your exceptions will be of the exact type you catch and this may result in the loss of exception information.

However, it seems that your library is throwing something not derived from std::exception - you need to find out what the type (ideally the base type) is.

1

I'm a bit confused. On the one hand you write catch(std::exception) didn't work (you should use catch(const std::exception&), BTW), on the other hand you also write you invoked std::exception::what(). How did you do this if you didn't have a std::exception in the first place?

Anyway, once you have caught anything but ..., you could try to log the RTTI info:

#include <typeinfo>

try {
  foreign_code(my_data);
} catch(const some_type& x) {
  std::cerr << "Yikes! Caught exception of type '" 
            << typeid(x).name() 
            << "' with its hand in the cookie jar!\n";
  std::abort();
}

While the standard doesn't make any assumptions of the result of std::type_info::name(), most (if not all) compilers will generate code that emits something that's at least somewhat useful.

When you're inside the VS debugger, you could also set it up so that it will stop at any exceptions thrown. That gives you a stack trace and thus might give you a clue as to what data passed to the DLL could have cause the problem.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • I don't understand how it solve its issue since he doesn't know what type to put in the catch (const some_type& x) if he had known that..he wouldn't need the RTTI information. – Itay Levin Mar 17 '10 at 09:06
  • @Itay, that's what I was confused about myself: user228058 wrote about invoking `std::exception::what()` - for which `some_type` must have been a `std::exception` descendant. ("How did you do this if you didn't have a std::exception in the first place? ") And above that code I explicitly wrote "[...] once you have caught anything but `...`, [...]". – sbi Mar 17 '10 at 14:00