On 15.12.20 13:18, David Osborne wrote:
So I have *removed* DSYSTEM_MALLOC from the default build flags and
created a new build... so far I've not been able to get that to crash
in test (where-as it was crashing every 3-4 requests when built with
DSYSTEM_MALLOC)
ah, when it was crashing
On Tue, 15 Dec 2020 12:18:57 +
David Osborne wrote:
> So I have *removed* DSYSTEM_MALLOC from the default build flags and created
> a new build... so far I've not been able to get that to crash in test
> (where-as it was crashing every 3-4 requests when built with
> DSYSTEM_MALLOC)
If it
Thanks very much Gustaf,
Looking in the build output I see the "-DSYSTEM_MALLOC" was already in
place during the build of the binary which is now crashing.
So I have *removed* DSYSTEM_MALLOC from the default build flags and created
a new build... so far I've not been able to get that to crash in
Dear David,
the crash looks like a problem in the OpenSSL memory management.
In general, i would believe that this is a problem in the NaviServer
code, but of the interplay of the various memory management options of
OpenSSL, NaviServer and Tcl. We use these functions under heavy load on
Hi,
We're building some Naviserver instances (4.99.19) on Debian Buster (v10.7).
One of the instances is a revproxy instance which uses connchans to speak
to a back end.
We're seeing very frequent signal 11 crashes of NaviServer with this
combination.
(We also see this infrequently with 4.99.18
