v5.5 segfault

[fredbcode]

Hi @philipianpearce @sunweaver

The latest changes breaks e2 (the load average is huge and e2 segfault) and I'm trying to understand why
At first #797 hard code limits for 32 and 64,bits, if I understand well, and the limit is very low for professional usage

So I added an optional compilation "--with-httpworkers=16384" to hardcode limit if necessary, uninformatively e2 still slow and segfault randomly, I guess I'm doing something wrong

Right now , I'm testing previous version pcre version, but I guess this is unrelated

Of course, this pull request is just for discussion, the issue still here

[fredbcode]

I confirm not related with pcre changes

[philipianpearce]

Fred, Note tests are failing on debianarm - How much memory is gitlab configured for this test?

If not enough for number of httpworkers - may explain slowness/no response/segfault.

Are you getting issues on a production set-up as well or just on gitlab?

[fredbcode]

Gitlab is broken yes, but for now I'm just using e2 in docker on x86, it "works" with a little load, but segfault after a while, no error with "previous" 5.5, yes seem worst with arm I will try to test on vm this week

[fredbcode]

I tried with 5000 workers, segfault

[fredbcode]

The ci part is fixed, working now with https://github.com/e2guardian/e2guardian/pull/798/files

[fredbcode]

I created a branch https://github.com/e2guardian/e2guardian/tree/ftempfix for my team, this branch works well at commit f6957c7

[philipianpearce]

Fred, I have reverted the pcre2 and httpworkers commit, so v5.5 should now be effectively back to commit f6957c7.

I have created a testpcre2 branch so that this can be tested further if needed. But as v5.5 should be stable release, will look at these updates in v5.6.dev to see the best way to implement them in more detail.

Thanks for all your investigation.
Philip

[fredbcode]

Perfect, I will fix CI

[fredbcode]

CI fixed https://gitlab.com/fredbcode/e2guardian/-/pipelines

Did you find an explanation about this issue ?