Re: Possible problem with shm_mq spin lock

On Sun, Oct 26, 2014 at 12:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> writes:
>> Thanks for the details. I am sorry It is not proc_exit. It is the exit
>> callback functions that can cause problem.
>
>> The following is the callstack where the problem can happen, if the signal
>> handler is called after the spin lock took by the worker.
>
>> Breakpoint 1, 0x000000000072dd83 in shm_mq_detach ()
>> (gdb) bt
>> #0 0x000000000072dd83 in shm_mq_detach ()
>> #1 0x000000000072e7db in shm_mq_detach_callback ()
>> #2 0x0000000000726d71 in dsm_detach ()
>> #3 0x0000000000726c43 in dsm_backend_shutdown ()
>> #4 0x0000000000727450 in shmem_exit ()
>> #5 0x00000000007272fc in proc_exit_prepare ()
>> #6 0x0000000000727501 in atexit_callback ()
>> #7 0x00000030ff435da2 in exit () from /lib64/libc.so.6
>> #8 0x00000000006ddaec in bgworker_quickdie ()
>
> Or in other words, Robert broke it. This control path should absolutely
> not occur: the entire point of the on_exit_reset call in quickdie() is to
> prevent any callbacks from being executed when we get to shmem_exit().
> DSM-related functions DO NOT get an exemption.

The "reset_on_dsm_detach" function is called to remove the DSM related
callbacks.
It's my mistake, I am really sorry, the code I am using is a wrong
one. Sorry for the noise.

Regards,
Hari Babu
Fujitsu Australia