# Confd\_notification\_ctx is getting corrupted leading to crash in confd\_notification\_send
**URL:** https://dmap-community.ductus.global/t/confd-notification-ctx-is-getting-corrupted-leading-to-crash-in-confd-notification-send/3174
**Category:** Core Engine and APIs
**Created:** [July 17, 2020, 9:12pm UTC](https://dmap-community.ductus.global/t/confd-notification-ctx-is-getting-corrupted-leading-to-crash-in-confd-notification-send/3174 "2020-07-17T21:12:39Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@desangol](https://dmap-community.ductus.global/u/desangol)
#### Post date: [July 17, 2020, 9:12pm UTC](https://dmap-community.ductus.global/t/confd-notification-ctx-is-getting-corrupted-leading-to-crash-in-confd-notification-send/3174/1 "2020-07-17T21:12:39Z")
when can confd\_notification\_ctx get corrupted and is there a way to check if confd\_notification\_ctx pointer is appropriate before calling confd\_notification\_send ?
---
### Author:  [@per](https://dmap-community.ductus.global/u/per)
#### Post date: [July 18, 2020, 3:19pm UTC](https://dmap-community.ductus.global/t/confd-notification-ctx-is-getting-corrupted-leading-to-crash-in-confd-notification-send/3174/2 "2020-07-18T15:19:51Z")
> [@desangol](#):
>
> when can confd\_notification\_ctx get corrupted
Well, not really corrupted, but when you call `confd_release_daemon()`, all confd\_notification\_ctx’s for the daemon will be de-allocated and thus unusable,
> [@desangol](#):
>
> is there a way to check if confd\_notification\_ctx pointer is appropriate before calling confd\_notification\_send ?
Not if it the memory it points to has been free()d - you will access basically random data whatever you do. When `confd_release_daemon()` is called (and a new daemon initialized), you need to make sure that `confd_register_notification_stream()` etc is called again for the new daemon, to obtain a new confd\_notification\_ctx.
---
### Author:  [@desangol](https://dmap-community.ductus.global/u/desangol)
#### Post date: [July 21, 2020, 3:56pm UTC](https://dmap-community.ductus.global/t/confd-notification-ctx-is-getting-corrupted-leading-to-crash-in-confd-notification-send/3174/4 "2020-07-21T15:56:36Z")
Thanks Per. I am getting “Daemon cpp\_confd\_agent timed out” in confd.log and “Worker socket query timed out daemon cpp\_confd\_agent id 6 in my confd” for my local devel log. Can you please tell me what does this signify.
---
### Author:  [@per](https://dmap-community.ductus.global/u/per)
#### Post date: [July 21, 2020, 4:31pm UTC](https://dmap-community.ductus.global/t/confd-notification-ctx-is-getting-corrupted-leading-to-crash-in-confd-notification-send/3174/5 "2020-07-21T16:31:59Z")
It means that ConfD sent a callback request to your daemon (if you use developerLogLevel “trace” in confd.conf you should be able to see which request it was), and didn’t receive a reply within the time specified for /confdConfig/capi/queryTimeout. ConfD will then consider your daemon hung or dead and close all the socket connections to it. This can’t per se explain your problem with the confd\_notification\_ctx though, but if you call confd\_release\_daemon() when you notice the socket close (and don’t obtain a new confd\_notification\_ctx), that could cause it.