Custom Query (101 matches)


Show under each result:

Results (1 - 3 of 101)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#1 fixed Maintaining, security and debugging enhancement request for zoo kernel soeren

I know that the current release is a proof of concept, so this request is related to the next release, but attached to the current.

While working on GIS GRASS ZOO integration, i faced several issues and obstacles using the zoo-kernel.

  • Parsing wrong commands from command line, or config files with incorrect content, as well as wrong python function bindings resulting in segfaults, which is a kind of frustrating finding errors while attaching new services.
  • There are inconsistencies between the command line interface and the cgi interface for Python services (different number of function arguments -> map, input and output vs. input, output)
  • Massive use of sprintf and strcmp instead of the more secure versions snprintf and strncmp
  • No check of correct memory allocation
  • Missing error messages in case something goes wrong with command line parsing, config file parsing and Python function bindings
  • Mixing C and C++ code (malloc and new operator used in one file)
  • The code need to be re-fractured to split huge functions into smaller parts to reduce redundancy and enhance the stability and maintainability
  • Better indention for better readability and maintainability
  • more issues will be added as new tickets

Hence i have modified several files in zoo-kernel because of security and stability reasons and added additionally debug output. The modification are made in the kernel and the python loader part.

  • Most of the memory allocation is now checked and warnings are printed if memory allocation fails
  • I have replaced sprintf with snprintf when possible
  • I have replaced strcmp with strncmp when possible
  • IMHO wrong memory allocation was fixed
  • Indention style for zoo_loader.c changed for better readability (using indent on Linux)

I may have implemented new bugs while trying to reduce them. :/ So intensive testing is needed.

Patch is attached.

#3 fixed Filling optional default values issue with GIS GRASS integration soeren

By default the zoo kernel fills all optional literal data inputs with default values. Thats fine in case default literal values are provided.

But here is the issue: optional literal data inputs are also attached in case no default values are available.

This results in something like "distance=NULL", which will in case of gis grass modules, abort the processing with an error.

There may be two solutions:

  1. The zoo kernel do not fill optional literal inputs when no default values are supported
  2. The zoo kernel uses the language specific way (None in case of Python) to specify missing default literal input values and the GIS GRASS integration framework will take care of parameter with attached NULL/None values

Both solutions are ok in case of literal data for me. The second one has the advantage, that the input map structure are fully available with literal data for service modules. So no new memory must be allocated/modified in case the developer decides to modify literal data in the input map.

Optional complex data inputs should IMHO not be filled. GIS GRASS has many modules with optional complex data inputs.

#5 fixed Segmentation fault on lineno in cgiMain djay relet

Following the instructions on the page "Zoo Kernel" - "Installation" for the svn installation, configured with

./configure --with-python=/usr/ --without-php --without-java 

(and optionally --without-js for the version 1.0) I ended up with a binary that segfaults in the first line of cgiMain() (line no. 140) calling dup2. The two file handles are equal, even before the call to dup2.

Calling it as cgi results in a segfault as well, I assume for the same reason.

1 2 3 4 5 6 7 8 9 10 11
Note: See TracQuery for help on using queries.


Context Navigation

ZOO Sponsors

Become a sponsor !

Knowledge partners

Become a knowledge partner

Related links