[dev.icinga.com #1253] SEGV in ido2db on Solaris with Oracle #561

Closed
icinga-migration opened this Issue Feb 28, 2011 · 8 comments

Projects

None yet

1 participant

@icinga-migration
Member

This issue has been migrated from Redmine: https://dev.icinga.com/issues/1253

Created by Tommi on 2011-02-28 20:40:54 +00:00

Assignee: Tommi
Status: Closed (closed on 2012-04-20 12:42:30 +00:00)
Target Version: (none)
Last Update: 2014-12-08 14:35:44 +00:00 (in Redmine)

Icinga Version: 1.10.0
OS Version: any

see http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=21804
There are 2 problemes

  1. cast from time_t (long) to unsigned long long in OCI_Bind
  2. Null Strings in printf ("%s",..)

Solution:
1.looks like there is no real usage of unsigned long long in the code, but please check back for measurement values
then replace all OCIBindUnsignetBigInt ((big_uint)...) with OCIBindUnsignetBigInt ((uint)..)
2. Make sure NULL values will be translated into real empty string e.g strdup("") and use functions from supplied snprintf.c in solaris. For this a modification of config.h (better in configure.in) is needed (switch off HAVE_VA_COPY and HAVE_C99_VSNPRINTF), dont use os provided functions like vfprintf which are not covered by snprintf.c. Take care, a syslog call includes such function internally

Attached are diffs for V1.3.0, which are working for me

Attachments

Changesets

2012-01-29 16:17:35 +00:00 by Tommi 06a7dee

fix build issues on modules and broken snprintf function causing segv on solaris #1772
refs #1772, #1253

2012-02-03 19:42:33 +00:00 by Tommi 543952f

idoutils logging: Fix non gcc compiler problems with gnu extension __printf__ #1253
refs #1253

2012-02-03 19:56:08 +00:00 by Tommi a7a9dd5

idoutils,core: add snprintf.h static header with definitions for configure time missed functions now available in snprintf.c .this fixes a lot of compiler warnings about undefined symbols
refs #1253

Relations:

@icinga-migration
Member

Updated by mfriedrich on 2011-03-16 17:44:15 +00:00

  • Target Version set to 1.4
@icinga-migration
Member

Updated by mfriedrich on 2011-03-24 22:05:49 +00:00

  • Status changed from New to Assigned
  • Assigned to set to Tommi

now it's yours ;-)

@icinga-migration
Member

Updated by mfriedrich on 2011-04-27 17:16:57 +00:00

  • Status changed from Assigned to Feedback

this might need some rework - or is it already done?

@icinga-migration
Member

Updated by Tommi on 2011-04-27 19:31:11 +00:00

  • Target Version changed from 1.4 to 1.5

My patch changes all number types at all, which is wrong approach we learned. Each data type needs to be checked if is large enough in database, sqlstring and coded c data type.

My "solution" regarding handling null strings you already rejected. I dont have a new one for now.
I just trying to build icinga with native Sun compiler (SunStudio), but there are a lot other problems with building dependencies.

@icinga-migration
Member

Updated by mfriedrich on 2011-07-16 16:10:57 +00:00

  • Target Version deleted 1.5

removing release target for proper resolution.

@icinga-migration
Member

Updated by Tommi on 2011-07-16 18:14:33 +00:00

i agree. It will take much more time to sort it out.
ocilib big_int handling is a mess, because it can be 4bytes or 8bytes depending of detecting longlong by ocilib in ocilib.h and recalculated when including it into icinga. Means you can build ocilib with 4byte big_int and build icinga using 8byte. longlong detection failed in linux up to 3.9.1, maybe this is the reason we dont run into problems until now, when casting pointers to bigint, because it was in every case only 4byte. See http://sourceforge.net/projects/orclib/forums/forum/470801/topic/4603198

@icinga-migration
Member

Updated by mfriedrich on 2012-04-20 12:42:30 +00:00

  • Status changed from Feedback to Closed
@icinga-migration
Member

Updated by mfriedrich on 2014-12-08 14:35:44 +00:00

  • Project changed from 18 to Core, Classic UI, IDOUtils
  • Category set to IDOUtils
  • Icinga Version set to 1
  • OS Version set to any
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment