Solved the issue the brute force way. Came up with a trivial application
using the existing CMake files. Once it crashed I backed out libraries
until it did not. Turns out it was gperftools and tcmalloc.
On Thu, Oct 28, 2021 at 2:48 PM Robert Middleton
wrote:
> I don't know how the loader works
I don't know how the loader works on OSX, but that seems somewhat
unlikely to me - either it should be complaining that the APR library
doesn't exist, or something related to APR should be in the stack
trace.
Unfortunately at this moment I'm just guessing wildly as to what the
issue may be. Witho
The example applications (at least trivial and console) run fine so dynamic
loading alone is not an issue (there are no static libs built). I do see
that we only reference the liblog4cxx library in our makefile while the
examples also reference the apr / apu libraries. Perhaps we need to tweak
ou
As far as I'm aware, the unit tests do use the dynamic library.
Looking at the stacktrace, I would expect the '--version' argument to
not work, since it seems to be happening before main() - my suspicion
is that your code has another static initialization(unrelated to
log4cxx) someplace, that is me
Hey Robert,
I agree that the socket issue is most likely unrelated. I'll try to look
at this.
I just noticed that our application supports '--version' which simply
prints the version and exits. Even using this results in the same segfault
so it seems the issue is more related to dynamic loading
The 'socketservertestcase' is probably not related to the issue at
all, but I've said that before about plenty of things and been wrong,
so I would recommend that you look into the reason that's failing
first. You may need to run the test manually in order to get more
useful output information. (m
Could this be a firewall configuration issue?
Matt Sicker
> On Oct 27, 2021, at 11:52, Bob Kirnum wrote:
>
> I am concerned that something may have changed on my system not directly
> related to the Monterey upgrade. We normally just use the dynamic library,
> I only built it now in order to
I am concerned that something may have changed on my system not directly
related to the Monterey upgrade. We normally just use the dynamic library,
I only built it now in order to help debug the issue. I was getting the
same segmentation fault prior to building from source.
Just ran the unit tes
Bob,
I don't use MacOS, so I don't know why that would happen. Builds on
MacOS through github actions are ok(but that is using 10.15).
Assuming that your stack trace is correct, it's complaining about line
159 in class.cpp, which is just 'return true'.
Are you able to run the unit tests at all?
Running application dynamically linked with log4cxx started crashing after
upgrading MacOs to Monterey. I tried building a debug version from source
but get the same error. Back trace shown below. Looks like something is
missing in the environment but there are no cmake or build errors. Any
sug
10 matches
Mail list logo
