Re: Realloc is blocking execution

[Mats Erik Andersson <mats.andersson@gisladisker.se>]

Dear mentors and coders,

the problem I observe with realloc() remains, so I will
present all the gory details. In order not to burden this
list with further extended mail exchanges, I would wellcome
a suggestion on continuing this thread on another list.
I will follow suite if a new list is named.

Now, back to realloc(). I have on my own tried some test
case similar to the one suggested by George Danchev, but
to no avail. In its own isolation, realloc() seems to work
well, which is a relief.

In the setting at hand, the problem appears within a running
window manager WM, and an outline of the mechanism is as follows,
represented as pseudo code, and most irrelevant preparations
are ignored. The outcome refers to Debian Lenny.


0. During initialisation of WM, these steps are performed:

      menutitems = malloc(1024) // 64 items of 16 bytes each

      Parse a user resource file, thereby filling a small number
      of items with two pointers, each pointing to strings allocated
      separately by malloc(). In fact,

            struct { char * a, * b;
                     int c, d;
               } menuitems[];

      menutitems = realloc(menuitems, 1024)  // Successful every time.
      
1. Standard duties commence and are running smoothly.
   An event loop waits for interaction.

2. The window manager WM responds to a user request by issuing

    execlp( /bin/sh -c "pkill -HUP WM" )

3. A signal SIGCHLD at the completion of step 2. is dealt with
   in an orderly fashion, and is finalized successfully.

4. The main process WM receives SIGHUP, and enters a signal handler.
   The signal handler uses two calls: free_menuitems(), get_menuitems().

5. The original structure menuitems is successfully returned
   to the memory heap for allocation. This was free_menuitems().

6. Call get_menuitems():

   a.   menutitems = malloc(1024)

   b.   Fill menuitems exactly like was done in step 0.

   c.   menuitems = realloc(menuitems, 1024)

        SLEEP-BLOCKING !!!!!!


Here Debian Lenny comes to a dead end. I once did wait for six minutes,
and still no sign of activity.

Hypothetical continuation:

   d.   return from get_menuitems()

7. Finalize SIGHUP by returning from signal handler.
   WM rewrites a small part of the window, and continues
   in its event loop.


Observe well, that the SIGHUP has not yet been finalized by the
time realloc() blocks execution (or sleeping undeterminably long!).
This seems to be the clue, due to the following alternative means
of user interaction.

2'.  Open an xterm client.

3'.  Issue "pkill -HUP WM" in that emulated terminal.

4'.  WM receives SIGHUP.

5'.  a'.  free_menuitems() is successful.

     b'.  Enter get_menuitems

     c'.  menuitems = malloc(1024)

     d'.  Parse resource file, fill fields into menutiems.

     e'.  menuitems = realloc(menuitems, 1024)  // Successful

     f'.  Return from get_menuitems().

6'.  Signal handler completed, thus SIGHUP has been finalized.

7'.  WM continues in event loop as expected.


I am certainly lacking in proper knowledge, but my thoughts
are following these lines:

    Could SIGHUP be messing with any system call induced
    by the library function realloc()?

    Could realloc() be waiting for retreival of the regions for
    which there are pointers stored inside "struct menuitems[]"?
    If so, why does this not always present a problem, severe
    enough to cause sleeping?


Best regards

Mats Erik Andersson, PhD