[Bug 53040] apache 2.4.1 Solaris 10 ssl virtual hosts dies after idle for a while

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=53040

--- Comment #5 from Georg Schaudy <gs...@gmail.com> ---
Created attachment 29187
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=29187&action=edit
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 http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html 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
(modules/cache/mod_socache_shmcb.c).
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
implementation.
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org