0

I debug an application which links against two DLLs. When an object from one of these DLLs is instantiated the application segfaults. However, when the order of the .lib files in (VS2010) Linker->Input->Additional Dependencies is swapped then the application runs fine.

This workaround works for now but I still want to understand what caused the problem. Any hints, how can I further debug this?

Geom
  • 827
  • 4
  • 15
  • If nothing has changed, [this](http://stackoverflow.com/q/2765403/1938163) might be the solution to your problem – Marco A. May 29 '15 at 07:48
  • This article discusses how to change the linking order. But I want to know why the linking order makes a difference to avoid such problems in the future. – Geom May 29 '15 at 08:00
  • It also says why, read carefully – Marco A. May 29 '15 at 08:00

2 Answers2

0

While without much more information any answer is bound to be a speculation, one potential reason is the following:

  1. in Windows, every DLL has DLLMain() function

  2. as soon as you have two DLLs, they will have two DllMain() function calls

  3. if there is a dependency between the two (i.e. one DLLMain() implicitly relies on an object being initialized within another one) - you have a problem.

I've seen such a problem myself (which is obviously a bad programming practice, but it does happen). However, a number of other explanations may also exist.

No-Bugs Hare
  • 1,557
  • 14
  • 15
0

The way to debug this would be the way to debug any crash: start by inspecting the stack at the catch of the segfault. If the crash reproduces at debug builds, understanding the direct reason should be straightforward (the root cause usually takes some deeper investigation).

Not much can be said about the cause of the crash without viewing this stack, but it is reasonable to assume that a global resource is involved. A named event, common temporary file, perhaps some internal framework structure (which, if any, frameworks are involved in your code?) - but it must be something that crosses the individual DLL boundaries, and so is probably a resource at application scope.

Ofek Shilon
  • 14,734
  • 5
  • 67
  • 101