apache-api/5188: Memory is moving around for no reason.

[Jason Anderssen <ja...@identikey.com>]

>Number:         5188
>Category:       apache-api
>Synopsis:       Memory is moving around for no reason.
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          support
>Submitter-Id:   apache
>Arrival-Date:   Fri Oct 22 19:40:00 PDT 1999
>Last-Modified:
>Originator:     janderssen@identikey.com
>Organization:
apache
>Release:        1.3.6
>Environment:
Linux 2.2.5-15
using gcc via apxs
>Description:
Hi,

I am sorry to bother you guys but i have gotten extremely desperate.

What happens is if I allocate memory for a structure that i wish to keep in memory for the life of the server funny things begin to happen.

I firstly set up a structure in the module declartion for logon profiles of people loging into the web server.  From here i wish to track people via a cookie that connect to the site and allow or not allow access to specific parts of the website.

In the module initilizer, i alloc memory for the structure, as people go to a certain page i log them with a cookie in the logon profiles structure that was initilized in the module initializer.  Now if i keep going to that page every second or two there is no problems with the profiles stored in memory. However if i wait approx 20 -30 seconds they are all gone and i start allocating profiles from the start again.  Give another 20 - 30 seconds and there back and the new ones have disappeared.

I have tried 'malloc' 'ap_palloc' and still get the same results?

I have also printed at the address of my pointer to the memory block everytime it is accessed and it doesn't move, it remains consistent.

Finally, if a store a few profiles in the module initilizer they stay for the lifetime of the module running (weird).

Now i do all the work in the content handler to store and find profiles, and i have a feeling that it is to do with apache storing the changes in the temp pool given to the content handler, and doesn't actually flush it to the real memory being setup in the module initilizer.

We have a release date on this project, and i dont want to have to go to NT/IIS if i can avoid it.  We already have the first system on NT, but i would like to create a much superior system for Unix and ultimately port it back to NT.

Please help

>How-To-Repeat:
create a module.

Define a structure

allocate memory in the module initilizer for the structure.
quickly at 1 or 2 entries to the strucuture.

now do some adding of entries in the content handler and print out the memory structure every 2 seconds for starters then let apache go idle for about 30 seconds and then check the memory.

I will now give you the structures i am using:

typedef struct _LogonProfile {

	char Cookie[Cookie_Size];
	char Username[48];
	char Password[32];
	char Challenge[128];
	char Response[32];
	time_t ExprTime;  //this memory will expire in a user defined time!!!!
	int PrimAuthPass;
	int ScndAuthPass;

} LogonProfile, *PLogonProfile;

typedef struct _LogonProfiles {

	LogonProfile Logons[MAX_LOGON_PROFILES];

} LogonProfiles, *PLogonProfiles;
>Fix:
Is there a way i can turn of apache doing memory management on my particular module is probably the first and fastest but not the best method of fixing this problem.

Cheers
Jason
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]