Custom Query (101 matches)


Show under each result:

Results (34 - 36 of 101)

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Ticket Resolution Summary Owner Reporter
#96 fixed Wrong macro names Knut Landmark

The Windows-specific macro _zStrdup occurring in function char *strcasestr(...) (zoo_service_loader.c) does not exist. Presumably it should be replaced by zStrdup (defined in service.h)

#95 fixed stdio functions and missing ExecuteResponse Knut Landmark

The standard stdio functions are shadowed by the fcgi_stdio functions in some but not all parts of the ZOO kernel. As tested on Windows, running a service (e.g. longProcess) with storeExecuteResponse=true and status=true may fail because the ExecuteResponse? is not written to the temporary <service>_final_<pid>.xml file via redirection of stdout. Putting #include "cgic.h" in service_internal.h resolved this problem.

Update: In some services it may be necessary to use standard stdio. For example, Visual C++ has a superset of wide character print functions, not redefined in fcgi_stdio.h, that take FILE* as a parameter (not FCGI_FILE*). This can easily be resolved by putting #define NO_FCGI_DEFINES at the beginning of the service source code.

#94 fixed getStatus function returns object allocated on the stack Knut Landmark

In the Windows version of the char* getStatus function (service_internal.c), the array

char lpszBuf[SHMEMSIZE];

is allocated on the stack, and then returned by casting lpszBuf to (char *). This may (and does) cause unexpected behavior (segmentation fault) because the stack memory for getStatus is automatically freed when the function returns. One solution is to allocate memory for lpszBuf dynamically using malloc (can be freed after each call to getStatus).

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Note: See TracQuery for help on using queries.


Context Navigation

ZOO Sponsors

Become a sponsor !

Knowledge partners

Become a knowledge partner

Related links