Argh, took me a find out what's going on. Will need some more time to actually produce a fix. Discovered all that while testing the changes to the tracer.
The application has a good chance crashing in prologue, if it's being attached to an existing process group. I guess those are the reasons I for the problems I complained on earler, that setting environment variables in 'ush' didn't change the tracing output. Problem #1: The prologue crash. The code in _initenv() provides a char[MAX_ENVIRONBLK] buffer to the _shared_getenvblk() function in shared.c That function expects a char** buffer, with independently allocated memory for every element. If the elements are !0, the getenvblk() tries to free them, and since the passed buffer contains uninitialized memory, so there is your crash, while attempting to free() a bogus pointer. Initializing the memory wouldn't solve the problem, as the rest of the env.c code will treat the filled buffer as a continuous block of memory with asciiz strings, terminated with an extra 0, where the getenvblk will return the array of char* pointers, that point to a newly allocated memory. Problem #2: environ variable. Though the environ variable is set up by the stdlib module of the newlib(environ.c), the actual code that deals with environment variables (setenv_r.c) has it's own pointer to it, called p_environ. The p_environ is of (char***) type, and is initialized with the value of &environ. The environ is of type (char*[]), and initialized to a constant array that contains a (null). The stdlib setenv_r implementation has a static tracking variable, that, once there is a modification to the environment block is done, (except for overwriting a variable with a smaller length value), the p_environ is reallocated. So it longer points to the environ. Also, since the initial environment block is always empty, the reallocation is quite guaranteed once any new variable is added. As a result of all the above, the rest of newlib code must never rely on the "environ" variable to do anything, as it's value will first always be stale. wince part of newlib seems to frequently use "environ" variable during spawn(). Problem #3: The _initenv() function in env.c and inherit_parent() function in startup.c seem to be trying to accomplish the same task of copying the environment variable of the shared process group into envuironment variable table. This is the least of the problems here :) I'm gonna go (unless you guys think I'm chasing geese here), and comb all this into a working model. This would most likely involve two things : getting rid of referencing environ directly from the wince specific code, and fixing the shared block updates/reads with regards to environment variables. While I'm coming up with the solution, I have two questions, anwering which would very much help me do the things right :) a. what's all the code in ceprocess.c / ceshared2.c, seems to do efforst to spawn applications, and deal with the shared memory, but in a different way, I'm just not sure when is this code called. b. Say a .c source declares an intialized static varable. When the .dll loads up, when does the initialization code gets executed? I hope it's before the dll entry point is jumped to. Thanks! Pawel. -- With best of best regards Pawel S. Veselov ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
