1

I'm working on Windows, in Visual Studio 2019, using librdkafka.redist NuGet package v1.50.

I've literally copy/pasted the librdkafka producer.cpp example code into my empty C++ project, changing only one line to be as follows:

#include <librdkafka/rdkafkacpp.h>

I've also modified build/native/librdkafka.redist.targets, replacing occurrences of "librdkafka.lib" with "librdkafkacpp.lib", because I'm working in C++.

The command line arguments are "127.0.0.1 test", in all cases. I'm running Kafka locally, and the topic is "test".

With this setup, the project builds and runs just fine as a release executable. I can type strings to produce, and they are produced to topic test.

If I switch to a debug configuration (32 or 64 bit, it doesn't matter), the program builds just fine, but on running it, it crashes as soon as it attempts to call:

conf->set("bootstrap.servers", brokers, errstr)

brokers is indeed "127.0.0.1" when this crash happens.

This is right after calling:

RdKafka::Conf* conf = RdKafka::Conf::create(RdKafka::Conf::CONF_GLOBAL);

I don't expect to step into the librdkafkacpp code, but it would be nice for it to actually function properly while running a debug executable.

I've also proven that the debug executable fails even if I don't run it under the debugger. It crashes with this error in the 64-bit exe.

Unhandled exception at 0x00007FF917F8C3F9 (msvcr120.dll) in KafkaFun.exe: 0xC0000005: Access violation reading location 0x0000002D4A150000.

Here's the error in the 32-bit exe:

Unhandled exception at 0x0100F41C (msvcr120.dll) in KafkaFun.exe: 0xC0000005: Access violation reading location 0xCD2BC8B0.

Something's clearly deeply wrong with the debug executables as I have built them. Do you have any idea what the problem is?

John Paquette
  • 11
  • 3
  • 1
    *I don't expect to step into the librdkafkacpp code* -- Why not? Maybe the answer to why it isn't working is just a few F11 keystrokes away. Second, you could also look at the call stack to see which function within the library and the line where it crashes on -- then inspect from there. – PaulMcKenzie Aug 19 '20 at 01:56
  • `msvcr120.dll` That would normally be `msvcr120d.dll` in a debug build. Check your build settings and the libraries you are linking to. – dxiv Aug 19 '20 at 02:16
  • PaulMcKenzie, it's because I'm using a NuGet package for librdkafka, and the package doesn't contain source code, nor a .pdb (debugging information) for librdkafkacpp. I cannot step into, except as assembly code. – John Paquette Aug 19 '20 at 16:31
  • @dxiv, Since I'm using a NuGet package for librdkafka, I just have DLLs for it. These are nondebug dlls, which have been linked with nondebug redistributable runtimes for the C runtime library. So it makes sense that they call msvcr120.dll rather than msvcr120d.dll. msvcr120.dll is included in the same directory as librdkafkacpp.dll. – John Paquette Aug 19 '20 at 17:04
  • What I'm doing here is trying to debug my program, a program which is using a nondebug dll which comes from a NuGet package. The nondebug dll has been linked with a nondebug redistributable C++ runtime dll, which is provided in the NuGet package. I could imagine maybe there's an issue due to conflicting C++ runtime libraries, but isn't my use case terribly typical? Is it not possible to write and debug a program which makes use of a NuGet package? – John Paquette Aug 19 '20 at 17:10
  • 1
    @JohnPaquette You may need to build the debug DLLs yourself, but you can't mix release and debug runtimes between modules that share them. – dxiv Aug 19 '20 at 17:11
  • Thanks. That's probably it. – John Paquette Aug 19 '20 at 17:11
  • 1
    This seems relevant: [link](https://stackoverflow.com/questions/11658915/mixing-debug-and-release-library-binary-bad-practice). The function which is crashing for me is expecting an `std::string`, which is identified as problematic by the link, because the `std::string` is created by one runtime, and consumed by another. Not good. – John Paquette Aug 19 '20 at 17:26

0 Answers0