Fwd: [ANNOUNCEMENT] Apache HTTP Server 2.4.69 Released

[Paul Smedley]

Hi folks,

It's been a while, but anyways.... https://smedley.id.au/tmp/httpd-2.4.69-os2-20261028.zip

Seems to work ok with plain html and with a mantis test site I have on my OS/2 box.

YMMV. I also have some planned enhancements to test based on Google Gemini evaluation of the OS/2 code in both APR and in the MPM code within Apache. I will release this as a separate build when it's ready - it may be more stable - or it may not <shrug>.

Cheers,

Paul

-------- Forwarded Message --------

Subject:	[ANNOUNCEMENT] Apache HTTP Server 2.4.69 Released
Date:	Thu, 01 Oct 2026 10:29:07 -0400
From:	covener <cov...@apache.org>
Reply-To:	anno...@httpd.apache.org
To:	anno...@httpd.apache.org
CC:	d...@httpd.apache.org

Apache HTTP Server 2.4.69 Released

October 01, 2026

The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.69 of the Apache
HTTP Server ("Apache"). This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache HTTPD and
represents fifteen years of innovation by the project, and is
recommended over all previous releases. This release of Apache is
a security, feature and bug fix release.

We consider this release to be the best version of Apache available, and
encourage users of all prior versions to upgrade.

Apache HTTP Server 2.4.69 is available for download from:

https://httpd.apache.org/download.cgi

Apache 2.4 offers numerous enhancements, improvements, and performance
boosts over the 2.2 codebase. For an overview of new features
introduced since 2.4 please see:

https://httpd.apache.org/docs/trunk/new_features_2_4.html

Please see the CHANGES_2.4 file, linked from the download page, for a
full list of changes. A condensed list, CHANGES_2.4.69 includes only
those changes introduced since the prior 2.4 release. A summary of all of the security vulnerabilities addressed in this and earlier releases is available:

https://httpd.apache.org/security/vulnerabilities_24.html

This release requires the Apache Portable Runtime (APR), minimum
version 1.5.x, and APR-Util, minimum version 1.5.x. Some features may
require the 1.6.x version of both APR and APR-Util. The APR libraries
must be upgraded for all features of httpd to operate correctly.

This release builds on and extends the Apache 2.2 API. Modules written
for Apache 2.2 will need to be recompiled in order to run with Apache
2.4, and require minimal or no source code changes.

https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

When upgrading or installing this version of Apache, please bear in mind
that if you intend to use Apache with one of the threaded MPMs (other
than the Prefork MPM), you must ensure that any modules you will be
using (and the libraries they depend on) are thread-safe.

Please note the 2.2.x branch has now passed the end of life at the Apache
HTTP Server project and no further activity will occur including security
patches. Users must promptly complete their transitions to this 2.4.x
release of httpd to benefit from further bug fixes or new features.



--
To unsubscribe from this announcement list, send a mail to
<announce-u...@httpd.apache.org> from your subscribed address.

[Massimo S.]

Il 28/10/2026 06:47, Paul Smedley ha scritto:
> Hi folks,
>
> It's been a while, but anyways.... https://smedley.id.au/tmp/httpd-2.4.69-os2-20261028.zip
>
> Seems to work ok with plain html and with a mantis test site I have on my OS/2 box.

Very very good.
Thanks a lot.

I've updgraded apache on the VM with only static html/js websites.

Server Version: Apache/2.4.69 (OS/2) OpenSSL/3.4.1
Server MPM: mpmt_os2
Server Built: Oct 28 2026 16:00:12

It seems to work well.

Performances seem improved than previous apache (2.4.61+ssl 1.1.1w), or it's just a feeling?

> YMMV. I also have some planned enhancements to test based on Google Gemini evaluation of the OS/2 code in both
> APR and in the MPM code within Apache. I will release this as a separate build when it's ready - it may be
> more stable - or it may not <shrug>.

Excellent.
Thanks.

massimo

> --
> You received this message because you are subscribed to the Google Groups "Apache for OS/2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> apache2+u...@googlegroups.com <mailto:apache2+u...@googlegroups.com>.
> To view this discussion visit
> https://groups.google.com/d/msgid/apache2/6d9d6ae8-99ce-4b2c-9c4b-51dd34994fcc%40smedley.id.au
> <https://groups.google.com/d/msgid/apache2/6d9d6ae8-99ce-4b2c-9c4b-51dd34994fcc%40smedley.id.au?utm_medium=email&utm_source=footer>.

[Massimo S.]

Il 28/10/2026 06:47, Paul Smedley ha scritto:

> Hi folks,
>
> It's been a while, but anyways.... https://smedley.id.au/tmp/httpd-2.4.69-os2-20261028.zip

Hi Paul,

you did some code optimization?
Since this build seems really faster.

I've updated also the AMP webserver and i repeat it seems much faster.

massimo

[Paul Smedley]

Hi Max,

None - this was a straight rebuild... however...

There is a new httpd.dll in https://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031.zip

This includes some tweaks suggested by Claude.ai, namely:

Likely real bugs

1. Out-of-bounds read in the slot searches (mpmt_os2.c master_main, mpmt_os2_child.c ap_mpm_child_main). The array access comes before the bounds check:

c

for (slot=0; parent[slot].pid != child_pid && slot < HARD_SERVER_LIMIT; slot++)

Swap the operands to slot < HARD_SERVER_LIMIT && parent[slot].pid != child_pid. The same applies to the child_slot loop.

2. Startup race between parent and child. spawn_child writes the child’s pid into the scoreboard after DosExecPgm returns, but the child looks itself up in the scoreboard at startup. If the child wins, it logs “child pid not found” and exits with APEXIT_CHILDFATAL, which makes the parent shut down the whole server. Either pass the slot to the child (environment variable or argument), or have the child retry the lookup for a second or two before giving up.

3. spawn_child ignores failure. After logging a DosExecPgm error it carries on and stores proc_rc.codeTerminate (uninitialised garbage) as the pid. Add a return; after the log.

4. worker_main carries on after DosOpenQueue fails. It logs “exiting” but doesn’t exit, then calls DosReadQueue on an uninitialised handle. It should set the slot to SERVER_DEAD and return.

5. Leaked thread slots in add_worker. The _beginthread return value isn’t checked. On failure (-1) the slot stays SERVER_STARTING forever and counts as alive. Reset it to SERVER_DEAD and log the error. The same unchecked call is used for the maintenance thread, and then DosWaitThread is called on whatever came back.

6. Pool leak in the accept loop. pconn is created every iteration, but on the non-fatal paths (EAGAIN, EINTR) it is never destroyed, so pools pile up under pchild. Call apr_pool_destroy(pconn) there, or create the pool only after a successful accept.

7. Broken round-robin across listeners. last_poll_idx is declared inside the do loop, so it resets to 0 every pass. The code always picks poll_results[0], and the >= num_listeners wrap can never trigger. It should be declared outside the loop and wrapped against num_poll_results, not num_listeners. Otherwise a busy first listener can starve the others.

&

Any accept error other than EAGAIN or EINTR is fatal to the whole server. Errors like ECONNABORTED and ECONNRESET are routine (a client resets between poll and accept). The worker/event MPMs treat these as non-fatal. EMFILE and ENOBUFS deserve a sleep and retry.

These don't seem to break anything. I'll try some load testing a bit later (siege?) and see if it improves things.

Feedback appreciated. I haven't committed these changes to github yet pending feedback.

Cheers,

Paul

[Paul Smedley]

Hi again,

http://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031b.zip contains the fixes above, and in addition:

8. DosSetRelMaxFH is relative, so it grows on every restart. mpmt_os2_run adds ap_thread_limit * 2 handles every time it runs, including each parent restart. Query the current maximum first (you already do), then only add the difference to reach the target.

9. HARD_THREAD_LIMIT is 256 in mpmt_os2.c and 254 in the child. The scoreboard is sized from the 256 returned by the query, but the child tracks only 254 slots. ID_FROM_CHILD_THREAD also uses a different stride from the scoreboard. The “move these to a header” XXXXXX comment is the right fix: put HARD_SERVER_LIMIT and HARD_THREAD_LIMIT in mpm_default.h (or a private header).

YMMV

Cheers,

Paul

[Paul Smedley]

And once more...

This one..

https://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031c.zip contains a list too long to detail of issues addressed in apr (apache portable runtime).

Build (c) includes all the fixes from (a) and (b) and is probably the 'riskiest' in terms of stability. I tried to smash my baremetal box with siege and 100 odd client and it barely raised a sweat similar to the other builds, but I know Max gets much more (and varied) load.

Cheers,

Paul

[Massimo S.]

Il 31/10/2026 03:59, Paul Smedley ha scritto:
> Hi again,
>
> On 31/10/26 08:33, Paul Smedley wrote:
>>
>> Hi Max,
>>
>> On 31/10/26 04:21, 'Massimo S.' via Apache for OS/2 wrote:
>>> Il 28/10/2026 06:47, Paul Smedley ha scritto:
>>>> Hi folks,
>>>>
>>>> It's been a while, but anyways.... https://smedley.id.au/tmp/httpd-2.4.69-os2-20261028.zip
>>>
>>> Hi Paul,
>>>
>>> you did some code optimization?
>>> Since this build seems really faster.
>>>
>>> I've updated also the AMP webserver and i repeat it seems much faster.
>>>
>> None - this was a straight rebuild... however...
>>
>> There is a new httpd.dll in https://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031.zip
>>
>> This includes some tweaks suggested by Claude.ai, namely:
>>
>>
>> Likely real bugs
>>

>> *1. Out-of-bounds read in the slot searches* (|mpmt_os2.c| |master_main|, |mpmt_os2_child.c|
>> |ap_mpm_child_main|). The array access comes before the bounds check:

>>
>> c
>> |for (slot=0; parent[slot].pid != child_pid && slot < HARD_SERVER_LIMIT; slot++)|
>>

>> Swap the operands to |slot < HARD_SERVER_LIMIT && parent[slot].pid != child_pid|. The same applies to the
>> |child_slot| loop.
>>
>> *2. Startup race between parent and child.* |spawn_child| writes the child’s pid into the scoreboard /after/

>> |DosExecPgm| returns, but the child looks itself up in the scoreboard at startup. If the child wins, it logs

>> “child pid not found” and exits with |APEXIT_CHILDFATAL|, which makes the parent shut down the *whole
>> server*. Either pass the slot to the child (environment variable or argument), or have the child retry the

>> lookup for a second or two before giving up.
>>

>> *3. |spawn_child| ignores failure.* After logging a |DosExecPgm| error it carries on and stores

>> |proc_rc.codeTerminate| (uninitialised garbage) as the pid. Add a |return;| after the log.
>>

>> *4. |worker_main| carries on after |DosOpenQueue| fails.* It logs “exiting” but doesn’t exit, then calls

>> |DosReadQueue| on an uninitialised handle. It should set the slot to |SERVER_DEAD| and return.
>>

>> *5. Leaked thread slots in |add_worker|.* The |_beginthread| return value isn’t checked. On failure (-1) the

>> slot stays |SERVER_STARTING| forever and counts as alive. Reset it to |SERVER_DEAD| and log the error. The
>> same unchecked call is used for the maintenance thread, and then |DosWaitThread| is called on whatever came
>> back.
>>

>> *6. Pool leak in the accept loop.* |pconn| is created every iteration, but on the non-fatal paths (EAGAIN,
>> EINTR) it is never destroyed, so pools pile up under |pchild|. Call |apr_pool_destroy(pconn)| there, or

>> create the pool only after a successful accept.
>>

>> *7. Broken round-robin across listeners.* |last_poll_idx| is declared inside the |do| loop, so it resets to

>> 0 every pass. The code always picks |poll_results[0]|, and the |>= num_listeners| wrap can never trigger. It

>> should be declared outside the loop and wrapped against |num_poll_results|, not |num_listeners|. Otherwise a

>> busy first listener can starve the others.
>>
>> &
>>

>> *Any accept error other than EAGAIN or EINTR is fatal to the whole server.* Errors like |ECONNABORTED| and

>> |ECONNRESET| are routine (a client resets between poll and accept). The worker/event MPMs treat these as
>> non-fatal. |EMFILE| and |ENOBUFS| deserve a sleep and retry.
>>
>> These don't seem to break anything. I'll try some load testing a bit later (siege?) and see if it improves
>> things.
>>
>> Feedback appreciated. I haven't committed these changes to github yet pending feedback.
>>
>>

http://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031b.zip contains the fixes above, and in addition:

Hi Paul,

thanks DLL installed, let's see how it goes.

massimo

> *8. |DosSetRelMaxFH| is relative, so it grows on every restart.* |mpmt_os2_run| adds |ap_thread_limit * 2|

> handles every time it runs, including each parent restart. Query the current maximum first (you already do),
> then only add the difference to reach the target.
>

> *9. |HARD_THREAD_LIMIT| is 256 in |mpmt_os2.c| and 254 in the child.* The scoreboard is sized from the 256

[Massimo S.]

Il 31/10/2026 06:07, Paul Smedley ha scritto:
> And once more...
>
> On 31/10/26 13:29, Paul Smedley wrote:
>>
>> Hi again,
>>
>> On 31/10/26 08:33, Paul Smedley wrote:
>>>
>>> Hi Max,
>>>
>>> On 31/10/26 04:21, 'Massimo S.' via Apache for OS/2 wrote:
>>>> Il 28/10/2026 06:47, Paul Smedley ha scritto:
>>>>> Hi folks,
>>>>>
>>>>> It's been a while, but anyways.... https://smedley.id.au/tmp/httpd-2.4.69-os2-20261028.zip
>>>>
>>>> Hi Paul,
>>>>
>>>> you did some code optimization?
>>>> Since this build seems really faster.
>>>>
>>>> I've updated also the AMP webserver and i repeat it seems much faster.
>>>>
>>> None - this was a straight rebuild... however...
>>>
>>> There is a new httpd.dll in https://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031.zip
>>>
>>> This includes some tweaks suggested by Claude.ai, namely:
>>>
>>>
>>> Likely real bugs
>>>

>>> *1. Out-of-bounds read in the slot searches* (|mpmt_os2.c| |master_main|, |mpmt_os2_child.c|

>>> |ap_mpm_child_main|). The array access comes before the bounds check:

>>>
>>> c
>>> |for (slot=0; parent[slot].pid != child_pid && slot < HARD_SERVER_LIMIT; slot++)|
>>>

>>> Swap the operands to |slot < HARD_SERVER_LIMIT && parent[slot].pid != child_pid|. The same applies to the
>>> |child_slot| loop.
>>>
>>> *2. Startup race between parent and child.* |spawn_child| writes the child’s pid into the scoreboard
>>> /after/ |DosExecPgm| returns, but the child looks itself up in the scoreboard at startup. If the child
>>> wins, it logs “child pid not found” and exits with |APEXIT_CHILDFATAL|, which makes the parent shut down
>>> the *whole server*. Either pass the slot to the child (environment variable or argument), or have the child

>>> retry the lookup for a second or two before giving up.
>>>

>>> *3. |spawn_child| ignores failure.* After logging a |DosExecPgm| error it carries on and stores

>>> |proc_rc.codeTerminate| (uninitialised garbage) as the pid. Add a |return;| after the log.
>>>

>>> *4. |worker_main| carries on after |DosOpenQueue| fails.* It logs “exiting” but doesn’t exit, then calls

>>> |DosReadQueue| on an uninitialised handle. It should set the slot to |SERVER_DEAD| and return.
>>>

>>> *5. Leaked thread slots in |add_worker|.* The |_beginthread| return value isn’t checked. On failure (-1)

>>> the slot stays |SERVER_STARTING| forever and counts as alive. Reset it to |SERVER_DEAD| and log the error.
>>> The same unchecked call is used for the maintenance thread, and then |DosWaitThread| is called on whatever
>>> came back.
>>>

>>> *6. Pool leak in the accept loop.* |pconn| is created every iteration, but on the non-fatal paths (EAGAIN,
>>> EINTR) it is never destroyed, so pools pile up under |pchild|. Call |apr_pool_destroy(pconn)| there, or

>>> create the pool only after a successful accept.
>>>

>>> *7. Broken round-robin across listeners.* |last_poll_idx| is declared inside the |do| loop, so it resets to

>>> 0 every pass. The code always picks |poll_results[0]|, and the |>= num_listeners| wrap can never trigger.

>>> It should be declared outside the loop and wrapped against |num_poll_results|, not |num_listeners|.

>>> Otherwise a busy first listener can starve the others.
>>>
>>> &
>>>

>>> *Any accept error other than EAGAIN or EINTR is fatal to the whole server.* Errors like |ECONNABORTED| and

>>> |ECONNRESET| are routine (a client resets between poll and accept). The worker/event MPMs treat these as
>>> non-fatal. |EMFILE| and |ENOBUFS| deserve a sleep and retry.
>>>
>>> These don't seem to break anything. I'll try some load testing a bit later (siege?) and see if it improves
>>> things.
>>>
>>> Feedback appreciated. I haven't committed these changes to github yet pending feedback.
>>>
>>>
>> http://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031b.zip contains the fixes above, and in addition:
>>

>> *8. |DosSetRelMaxFH| is relative, so it grows on every restart.* |mpmt_os2_run| adds |ap_thread_limit * 2|

>> handles every time it runs, including each parent restart. Query the current maximum first (you already do),
>> then only add the difference to reach the target.
>>

>> *9. |HARD_THREAD_LIMIT| is 256 in |mpmt_os2.c| and 254 in the child.* The scoreboard is sized from the 256

>> returned by the query, but the child tracks only 254 slots. |ID_FROM_CHILD_THREAD| also uses a different
>> stride from the scoreboard. The “move these to a header” XXXXXX comment is the right fix: put
>> |HARD_SERVER_LIMIT| and |HARD_THREAD_LIMIT| in |mpm_default.h| (or a private header).
>>
> This one..
>
> https://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261031c.zip contains a list too long to detail of issues
> addressed in apr (apache portable runtime).
>
> Build (c) includes all the fixes from (a) and (b) and is probably the 'riskiest' in terms of stability. I
> tried to smash my baremetal box with siege and 100 odd client and it barely raised a sweat similar to the
> other builds, but I know Max gets much more (and varied) load.
>
> Cheers,
>
> Paul

Hi,

i've installed the build "B", do you suggest ot instal the build "C"?

massimo

[David McKenna]

Paul,

  I've installed the 'c' version and so far it seems fine. I'll let you know if anything comes up - thanks!

Regards,

[Paul Smedley]

Hi Max,

I suggest build 'B' and is that shows no issues, then install build 'C'.
If you go straight to 'C' and you see issues, we won't know if they are
causes by the changes to apache2 or to apr.

Cheers,

Paul

[Massimo S.]

Hi,

with this build "B" i've stuff like this (like in the past), is this ok?

Apache/2.4.69 (OS/2) OpenSSL/3.4.1 PHP/7.4.32 configured -- resuming normal operations
[Mon Nov 02 22:32:34.261000 2026] [mpm_mpmt_os2:notice] [pid 264:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:32:34.294000 2026] [mpm_mpmt_os2:notice] [pid 262:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:32:34.306000 2026] [mpm_mpmt_os2:notice] [pid 264:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:32:34.539000 2026] [mpm_mpmt_os2:notice] [pid 263:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:32:34.572000 2026] [mpm_mpmt_os2:notice] [pid 262:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:33:15.822000 2026] [mpm_mpmt_os2:notice] [pid 264:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:33:15.826000 2026] [mpm_mpmt_os2:notice] [pid 263:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:33:15.857000 2026] [mpm_mpmt_os2:notice] [pid 264:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:33:16.177000 2026] [mpm_mpmt_os2:notice] [pid 262:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:33:18.818000 2026] [mpm_mpmt_os2:notice] [pid 263:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:33:19.058000 2026] [mpm_mpmt_os2:notice] [pid 263:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 22:37:02.709000 2026] [mpm_mpmt_os2:notice] [pid 264:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 23:47:26.661000 2026] [mpm_mpmt_os2:notice] [pid 264:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept
[Mon Nov 02 23:51:13.989000 2026] [mpm_mpmt_os2:notice] [pid 264:tid 1] (OS 10035)Resource temporarily
unavailable: apr_socket_accept

massimo

[Paul Smedley]

HI Max,

I fed this into Claude - it reckons this is noise...

"That’s OS/2 socket error 10035 (EWOULDBLOCK), caused by non-blocking
listeners plus accept-mutex release before accept() in mpmt_os2_child.c.
It’s harmless, but I’ll make prefork-style children hold the mutex
across accept to quiet the expected case"

It has provided a fix, but I trying to built qtwebengine so I have no
spare cpu cycles.

Cheers,

Paul

[David McKenna]

FWIW - I see a good many of that message as well. Always thought it was noise because it never presaged any problems...

Regards,

[m...@ecomstation.it]

Yes, it's not an issue, but if this noise write too much in the logs it can create overhead.

massimo

>>>>>> None - this was a straight rebuild... however....

listeners plus accept-mutex release before accept() in mpmt_os2_child.c..

It's harmless, but I'll make prefork-style children hold the mutex
across accept to quiet the expected case"

It has provided a fix, but I trying to built qtwebengine so I have no
spare cpu cycles.

Cheers,

Paul

--
You received this message because you are subscribed to the Google Groups "Apache for OS/2" group.

To unsubscribe from this group and stop receiving emails from it, send an email to apache2+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/apache2/2433fdb1-b0a8-492d-b77c-aff553ae7394n%40googlegroups.com.

[Paul Smedley]

Claude came up with a fix, I'll include it in a future build.

To view this discussion visit https://groups.google.com/d/msgid/apache2/a10b5a4f0e81998f1ae85ef8cbb3913e%40ecomstation.it.

[Paul Smedley]

Folks,

https://smedley.id.au/tmp/httpd-2.4.69-os2-dll-20261104.zip contains a test build with this change. It also includes the changes that were in 20261031c.zip

Some detail on the httpd changes is at https://github.com/psmedley/httpd-2.4-os2/pull/17

Details of the APR changes are at https://github.com/psmedley/apr-os2/pull/1

Cheers,

Paul

[David McKenna]

Thanks Paul - I've loaded it and we'll see how it holds up.One thing in the error.log I've seen a good bit of with these new builds (but not previously) is this warning:

[57642:22] PTHREAD: WARNING: TlsAllocEx: no more TLS bits available

 Not sure if it's anything to worry about, but would be interesting to know what Claude makes of it.

Regards,

[Massimo S.]

Hi Paul,

i've some exceptQ dumps of apache 2.4.69 (some in the apache+php web srv and some in the
apache html/js only static websites web srv).

I'm using HTTPD fix build "B" in both VMs.

Let me know if you want to see the dumps of i've to upgrade to build "D" (20261104)

Thanks.


Exception Report - created 2026/11/06 04:44:28
______________________________________________________________________

LIBC: Killed by SIGSEGV

Hostname: mysrv
OS2/eCS Version: 2.45
# of Processors: 4
Physical Memory: 3071 mb
Virt Addr Limit: 2560 mb
Exceptq Version: 7.11.6.2-shl (Dec 31 2023 21:17:47)

______________________________________________________________________

Exception C0000005 - Access Violation
______________________________________________________________________

Process: X:\APACHE\BIN\HTTPD.EXE (10/28/2026 05:37:28 1,749)
PID: 5C0 (1472)
TID: 01 (1)
Priority: 200

Filename: N/A
Cause: Invalid execution address 1CEF00BE
Exception Registration Record Chain

______________________________________________________________________

Registration Record Chain
______________________________________________________________________

0012F8C4 Handler 1FFCA330 Prev 0012FF54 DOSCALL1 0002:0000A330 _xcptR3ExceptionHandler
0012FF54 Handler 1EB7F270 Prev 0012FF7C LIBCX0 0001:0000F270 main.c#80 libcxExceptionHandler
0001:0000F270 (.\libcx-0.7.5\src\main.c)
0012FF7C Handler 1EC0F9DC Prev FFFFFFFF LIBCN0 0001:0007F9DC exceptions.c#75
__libc_Back_exceptionHandler 0001:0007F9DC (exceptions.obj)

______________________________________________________________________


massimo

>> <https://groups.google.com/d/msgid/apache2/2433fdb1-b0a8-492d-b77c-aff553ae7394n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google Groups "Apache for OS/2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> apache2+u...@googlegroups.com <mailto:apache2+u...@googlegroups.com>.

> To view this discussion visit

> https://groups.google.com/d/msgid/apache2/69e86b82-e2cc-49f7-9755-925686a48903%40smedley.id.au
> <https://groups.google.com/d/msgid/apache2/69e86b82-e2cc-49f7-9755-925686a48903%40smedley.id.au?utm_medium=email&utm_source=footer>.

[Paul Smedley]

Sure, send them through off list.

[Massimo S.]

Hi Paul,

i had an exit of apache + php 20261104 (build "B") + php2shell on the webmail server
(round cube).

It exited and left an httpd child unkillable, i had to setboot /b and server hang
on "system is rebooting" since the OS was not able to kill the process.

I've created a pdumpctl httpd r f d o about the "http zombi process",
the zip archive is about 9,5MB.
Let me know if you need it.

I've a number of these traps in \var\log\app ..

Opened log at 2026-11-06 14:37:02.59 (03250c9c ms since boot)
Process ID: 0x1ece (7886) Parent PID: 0xe (14) Type: 2 Codepage: 850
Exe hmte : 0x109c (D:\APACHE\BIN\HTTPD2.EXE)
Arg 0 : "X:\apache\bin\httpd2.exe" (25)
Arg 1 : "-d X:\apache " (14)
Cur dir : X:\apache
CRT Module: LIBCN0 hmod=0x593 (C:\USR\LIB\LIBCN0.DLL)
__libc_logInit: addr 0x1f223408 iObj=0 offObj=0x63408
Origin : libcx
LIBCx version : 0.7.5
LIBCx module : C:\USR\LIB\LIBCX0.DLL (hmod=053b)
Millsecond Timestamp.
| Thread ID.
| | Log Group (Asrt for assertions).
| | | File Name.
| | | | Line Number.
| | | | | Function Name.
v v v v v v
xxxxxxxx tt gggg file:line:function: message
03250c9c 01 Asrt shared.c:214:shared_init: Assertion failed: arc == NO_ERROR (105)


thanks

massimo