[Plplot-general] Problem with color map1 and the tk driver

[Dean C. <de...@qu...>]

I found that when I ran the demo x08c with the tk driver it blew up. With a 
little work I traced the problem to the call to plscmap1. Then after a lot more 
work I found that the problem is in plr.c.  In routine plr_state in the 
PLSTATE_CMAP1 case ot the switch there is no check made to see if the requested 
number of colors has been allocated in cmap1. It needs to be changed to 
something like:

    case PLSTATE_CMAP1:{
        U_SHORT ncol1;

        plr_rd( pdf_rd_2bytes(plr->pdfs, &ncol1) );
        if( ncol1 > plsc->ncol1 ){
          plsc->cmap1 = (PLColor *) realloc(plsc->cmap1, ncol1 * 
sizeof(PLColor)
 );
        }
        plsc->ncol1 = ncol1;
        for (i = 0; i < plsc->ncol1; i++) {
            plr_rd( pdf_rd_1byte(plr->pdfs, &plsc->cmap1[i].r) );
            plr_rd( pdf_rd_1byte(plr->pdfs, &plsc->cmap1[i].g) );
            plr_rd( pdf_rd_1byte(plr->pdfs, &plsc->cmap1[i].b) );
        }
        plP_state(PLSTATE_CMAP1);
        break;
   }

I believe the PLSTATE_CMAP0 case should be similarly patched.

In the process of finding this bug I found some problems with the debugging 
routines supplied. First the pldebug routine does not print the correct line 
and file - it always prints the same line number in the file pldebug.h. In 
order to fix this problem I changed the calling sequence to pldebug to pass in 
the line and file. The call would look something like:

        pldebug( __LINE__, __FILE__, "plr_state", "PLSTATE_CMAP1\n" );

I also found that it was difficult to find out what was going on on the server, 
so I added some options to the run parameters:

-debugfile name - causes any debug output to go to the file "name". By default 
it goes to stderr.

-sdebug - causes the program to run the server with the -debug option so that 
debugging output will happen on the server

-sdebugfile name - similar to -debugfile but it is passed to the server

If anyone is interested in these changes, please contact me. My version of the 
source has now changed quite a bit in order to instrument the programs 
sufficiently enough to find out what was going on. Unfortunately, I did not 
keep very good track of what I changed.

Were any of these problems addressed in the 5.0.2 release?

Dean Clamons
Code 7420
Naval Research Lab
Washington, DC 20375
202-767-2732