Opened 13 years ago
Closed 13 years ago
#3813 closed defect (fixed)
STYLEITEM AUTO Broken using FastCGI since rendering merge
Reported by: | aboudreault | Owned by: | sdlime |
---|---|---|---|
Priority: | normal | Milestone: | 6.0 release |
Component: | MapServer FastCGI | Version: | unspecified |
Severity: | normal | Keywords: | fastcgi, styleitem auto |
Cc: | dmorissette, sdlime, tbonfort |
Description
I'm not sure where the problem is... but it seems that r10743 broke something in the FastCGI implementation when a map is using STYLEITEM AUTO. I'm not sure at 100% that styleitem auto is is really related to the issue... but I don't see any error message when I don't use it. here's what I see in the log file:
[Wed Apr 6 13:36:42 2011].467399 msOGRFileNextShape: Returning shape=1, tile=0 [Wed Apr 6 13:36:42 2011].467460 getSymbol(): Symbol definition error. Parsing error near (aaa):(line 1100) [Wed Apr 6 13:36:42 2011].467481 ** Using 'sans' TTF font ** [Wed Apr 6 13:36:42 2011].468099 msOGRFileNextShape: Returning shape=2, tile=0 [Wed Apr 6 13:36:42 2011].468169 getSymbol(): Symbol definition error. Parsing error near (ddd):(line 1100) [Wed Apr 6 13:36:42 2011].468188 ** Using 'sans' TTF font ** ...
I've attached a test case to reproduce the bug. The same test case without using FastCGI work properly. Mapserver at r10742 with FastCGI also work properly.
Attachments (1)
Change History (9)
by , 13 years ago
Attachment: | 3813.tar.gz added |
---|
comment:1 by , 13 years ago
Cc: | added; removed |
---|
comment:2 by , 13 years ago
- The getSymbol() error report is normal and has nothing to do with the failure. We also see it in non-fastcgi request.
- STYLEITEM auto has nothing to do with the failure.
The failure still exists in FastCGI... but only when we use GD driver. It seems that we just can't use GD in FastCGI... but I still need some investigation to be sure.
comment:3 by , 13 years ago
I tried another map (gmap) that works with normal CGI and it crashes in FastCGI with GD driver. The map is drawn properly in fastCGI using AGG driver though.
comment:4 by , 13 years ago
Furthermore, here's the difference between AGG and GD:
- AGG uses the method saveAsPNG to save the image to stdout.
- GD uses the method saveGdImage to save the image to stdout. With GD, I see the images printed in the apache2/error.log.
comment:5 by , 13 years ago
The issue seems that the gd driver doesn't use gdIOCtx at all in 6.0, which is required to use the fastCGI stdout. Not sure what's the proper way to do it in the rendering functions.
comment:6 by , 13 years ago
We should probably look back to the old GD implementation for guidance. I took the simple approach when I started the GD migration and certainly could have missed a bit on the output side.
Steve
test case