httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 53040] apache 2.4.1 Solaris 10 ssl virtual hosts dies after idle for a while
Date Wed, 08 Aug 2012 15:10:35 GMT

--- Comment #5 from Georg Schaudy <> ---
Created attachment 29187
Experimental patch of mod_socache_shmcb.c

That guess hits the nail on the head! This is indeed a memory alignment issue
on SPARC systems!
See for
a good description of the basic problem.
We compiled httpd 2.4.2 (32bit) on SPARC Solaris 10 using gcc, and experienced
the "Bus error" issue as described above.

It turns out to be an issue with the shmcb implementation
The problem is the SHMCBIndex structure having a member "expires" of type
apr_time_t (long long). This needs to be 8 byte aligned, otherwise it will
cause a Bus error on access!

However, the SHMCBIndex objects are nested within subcaches, which are
prepended by an SHMCBHeader structure.
The memory allocation inside the SHM segment looks more or less like this:

                              [ expires, ...] [ expires, ...]
              [ SHMCBSubcache | SHMCBIndex   ,  SHMCBIndex   , ... | Data ]
[ SHMCBHeader | subcache 0                                                 ,
Alignment:                      ^8 byte         ^8 byte

                 [ expires, ...]
 [ SHMCBSubcache | SHMCBIndex   , ... ]
   subcache 1                          , ... ]
Alignment:         ^8 byte

Having got so far, I found a fix that is not pretty, but quite simple and
unintrusive. On the downside it depends heavily on the details of the current
The obvious way to ensure correct alignment of the SHMCBIndex structures seems
to be to make sure all the building blocks' sizes are a multiple of 8 bytes.
This is already the case for SHMCBSubcache (size=16), and SHMCBIndex (24), but
not for SHMCBHeader (52).
The size of the subcache's "Data" segment (subcache_data_size) is calculated at
startup and depends on the configured SSLSessionCache size. (For the default it
is 14180 ( % 8 = 4), which means that every other subcache will fail!)

The attached patch works on our system.
Maybe you can find a more elegant / robust fix for this issue!

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message