Re: Patch for curses module

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

You are apparently right, it wasn't the next color pair that fixed
white/black, but new creation of white/black that at one time
succeeded.

I'm now trying to provide a clean memory block for the zalloc call by
doing preceding 16 byte allocations and frees. The 16 bytes comes from
size of colorpairnode struct. It's 16 on x86 and 32 on 64 bit machine.
I am hoping that zalloc will reuse the memory blocks. Doing simple
test in C showed that it's reasonable to expect this:

#include <stdlib.h>
#include <stdio.h>

int main() {
    char * a = (char*) malloc(16);
    free(a);
    char * b = (char*) malloc(16);
    free(b);

    printf(" %p vs %p ", a, b );
    return 0;
}

The test worked on FreeBSD, OSX and Linux. I also added traces to
zalloc() to ensure that it will call malloc(16), and obtained that
this will be done for 15 chars long string assignment (but not for 15
zeros '$\0...', what's interesting).

So I do the following before calling zcurses:

_provide_clean_memory_to_old_zsh() {
    local i=100
    while (( i-- )); do
        local a b
        a="               "
        b="               "
        unset a b
    done
}

The disabled flag is defined as follows:

#define DISABLED        (1<<0)

Hash node which is part of colorpairnode as:
struct hashnode {
    HashNode next;          /* next in hash chain */
    char *nam;                  /* hash key           */
    int flags;                      /* various flags      */
};

Therefore filling a 16/32 byte area with zeros or e.g. spaces and then
freeing it should provide proper memory for zcurses. But this doesn't
happen. Does unset free memory? What can be done to allocate and free
16/32 bytes block?

Best regards,
Sebastian Gniazdowski

On 12 September 2015 at 20:33, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Sep 12,  7:40pm, Sebastian Gniazdowski wrote:
> }
> } I wonder how can creating subsequent color pair make previous pairs
> } non-disabled. It happens in random manner, sometimes it helps and
> } sometimes not. In first reply I attached a log where red/black fixed
> } white/black
>
> Looking at your trace, I see white/black being created twice, the
> second time after it was cache-missed for DISABLED but also before
> the red/black is created.  The second time white/black is created
> is when I believe it "fixes" the DISABLED bit.
>
> Am I misreading the trace, or misunderstanding the sequence of events
> that created the trace?