Custom Query (101 matches)
Results (34 - 36 of 101)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#96 | fixed | Wrong macro names | Knut Landmark | |
Description |
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 | |
Description |
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 | |
Description |
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). |