Re: [Nagios-devel] [Nagios-users] external commands and segfault --
Posted: Mon Jan 08, 2007 7:48 am
David G Schlecht wrote:
> Helmut W. Januschka krone.at> writes:
>
>> You may move the strlen() to a sperate variable
>> And after that reproduce the gbd session and use "info locales" to see
>> What are the actual values of the variables and maybe just the strlen fails
>>
>> Also try "print name1" and "print name1" and look if there are some
> unterminated strings
>> And backtrace to where the call to the hashfunc2 occurs and have a look at
> the value wich originally gots
>> sended in
>>
>> Maybe its just a old version or a bad implemantion of the tool submitting the
> external command (sure nagios
>> should do a segfault at all
)
>>
>
>
> Thanks for your reply, Helmut. From the segfault, it appears that
> both name1 and name2 are corrupt as both are outside the program's
> address space. Since name1 is received as a const, it's unlikely
> that this routine (hashfunc2) is causing the problem. The calling
> routine (find_service) doesn't change the contents of the variable
> so it's not likely the problem. Tracing all the way back,
> event_execution_loop seems the most likely cause of the segfault.
> However this is not a trivial routine and I'm not able to debug it.
> Is there anyone familiar enough with the code available to take a look?
>
> This problem doesn't occur with each external command, but only
> once every 200-300 times.
>
> Any help would be most appreciated.
>
I think you'd have better luck posting this to the nagios-devel list, so
I'm cross-posting it there now. Provided you're subscribed there, we
should be able to drop this from the nagios-users list where it really
doesn't belong.
Anyways...
What command is being sent into the command-pipe when nagios crashes?
Have you made any modifications to the code?
Does this happen with latest CVS code (without any local modifications)?
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> Helmut W. Januschka krone.at> writes:
>
>> You may move the strlen() to a sperate variable
>> And after that reproduce the gbd session and use "info locales" to see
>> What are the actual values of the variables and maybe just the strlen fails
>>
>> Also try "print name1" and "print name1" and look if there are some
> unterminated strings
>> And backtrace to where the call to the hashfunc2 occurs and have a look at
> the value wich originally gots
>> sended in
>>
>> Maybe its just a old version or a bad implemantion of the tool submitting the
> external command (sure nagios
>> should do a segfault at all
)>>
>
>
> Thanks for your reply, Helmut. From the segfault, it appears that
> both name1 and name2 are corrupt as both are outside the program's
> address space. Since name1 is received as a const, it's unlikely
> that this routine (hashfunc2) is causing the problem. The calling
> routine (find_service) doesn't change the contents of the variable
> so it's not likely the problem. Tracing all the way back,
> event_execution_loop seems the most likely cause of the segfault.
> However this is not a trivial routine and I'm not able to debug it.
> Is there anyone familiar enough with the code available to take a look?
>
> This problem doesn't occur with each external command, but only
> once every 200-300 times.
>
> Any help would be most appreciated.
>
I think you'd have better luck posting this to the nagios-devel list, so
I'm cross-posting it there now. Provided you're subscribed there, we
should be able to drop this from the nagios-users list where it really
doesn't belong.
Anyways...
What command is being sent into the command-pipe when nagios crashes?
Have you made any modifications to the code?
Does this happen with latest CVS code (without any local modifications)?
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]