free() returns SIGSEGV randomly on a sparse zone of solaris 10. Why?

Question

I am working on a open source tool "zabbix" and it works very fine on RHEL/ Global Zone of Solaris 10. But the problem seems confusing when I try to run this tool on a sparse zone of Solaris 10. On the sparse zone, the tool works sometimes and sometimes it crashes with SIGSEGV signal. This signal is raised while freeing up the memory allocated by a variable.

Please see below the exact codes where this signal is raised:

void    free_request(AGENT_REQUEST *request)
{
    int i;

    zbx_free(request->key);

    for (i = 0; i < request->nparam; i++)
        zbx_free(request->params[i]);
    zbx_free(request->params);

    request->nparam = 0;
}

Please be informed that this part of code runs flawlessly on Linux or any Global Zone of Solaris 10.

Now, you might point that may be zbx_free() is trying to free some variable which is already free. I would say, NO. because I have debugged the code and found that the allocation of the variable was legitimate before zbx_free() tried to free the variable and consequently raised SIGSEVG signal.

You may want to look into the macro zbx_free(request->key) (It is a macro but function). Please see below, as this is very simple too.

do              \
{               \
    if (request->key)       \
    {           \
        free(request->key); \
        request->key = ((void *)0); \
    }           \
}               \
while (0)

So, In my opinion the question hovers between "sparse zone" and "Global zone". I assume, Global zone is restricting sparse zone to free() memory allocation. If it is true, then could someone please help me to solve this issue? Please suggest me the workaround, if any.

Thanks for your time.

Regards,

Rohit

Is it possible that you've assigned less memory to the sparse zone, and one of the allocations is failing, which leads to the free causing a `SEGV`? — Anya Shenanigans, Jun 26 '14 at 09:29
If it was linux I would cry use valgrind, but a slightly more solaris solution is to use `libumem`. `LD_PRELOAD=libumem.so.1 UMEM_DEBUG=default run_app`. I *seriously* doubt it's a zone thing. — Anya Shenanigans, Jun 26 '14 at 10:43
I think I have no option left other than libumem. But still i don't understand that why this working in Global zone but sparse zone. Don't you think that kernel is affecting the memory management of sparse zone (as we know that all zones share same kernel) ? — Rohit, Jun 26 '14 at 18:52

Rohit · Answer 1 · 2014-07-03T10:48:57.273

@Petesh:

Sorry for my last answer. Though it worked for a while but was not an absolute solution. The tool crashed several time at the point of freeing memory as well as at the point of memory allocations also.

Later, I tried valgrind to find out the solution on Linux. And I found several improper uses of malloc (like less size of memory allocation, etc). I fixed them and found that freeing issue never stroked back. The tool has not crashed at this point ever. Thanks to Valgrind and @Peetesh for your recommendation.

free() returns SIGSEGV randomly on a sparse zone of solaris 10. Why?

1 Answers1