[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sapdb-general
Subject:    RE: devtools: ptoc can't find pgenc
From:       Christian Bienia <cbienia () CS ! Princeton ! EDU>
Date:       2006-08-15 4:00:10
Message-ID: 1155614410.5567.120.camel () cbienia
[Download RAW message or body]

Hi,

you're right, and it turned out it's not due to pgenc. The bug is in
sete, which cannot handle path names longer than 80 characters. If TOOL
is set, ptoc segfaults in that case. The reason is the fixed size of
linebuf, which will be written to by sprintf:

static sete ( gdir , s )
char    **gdir ;
char    *s ;
{
    char        *tooldir ;
    char        *pos ;
    char        linebuf[80] ;

    /* MWa extern char *malloc () ; */

    tooldir = getenv ("TOOL") ;
    sprintf ( linebuf , "%s/%s" , tooldir , s ) ;

    if (( pos = malloc ( strlen ( linebuf ) + 1 )) == NULL )
    {
        perror ("malloc") ;
        exit (1) ;
    }

#ifdef _IBMR2
    strcpy ( (unsigned char *) pos , (unsigned char *) linebuf ) ;
#else
    strcpy ( pos , linebuf ) ;
#endif
    *gdir = pos ;
}


All versions of the maxdb-buildtools are affected, including the
pre-compiled ones (I wrote earlier that the pre-compiled buildtools work
correctly, but that was merely because they were at a location that
resulted in a shorter path). Once I realized that, the bug was easy to
fix. I removed the unnecessary linebuf and let sprintf write directly to
pos. The following version of sete works for me:

static sete ( gdir , s )
char    **gdir ;
char    *s ;
{
    char        *tooldir ;
    char        *pos ;

    /* MWa extern char *malloc () ; */

    tooldir = getenv ("TOOL") ;

    /* Complete string: tooldir + '/' + s + '\0' */
    if (( pos = malloc ( strlen ( tooldir ) + strlen ( s ) + 2 )) ==
NULL )
    {
        perror ("malloc") ;
        exit (1) ;
    }

    sprintf ( pos , "%s/%s" , tooldir , s ) ;
    *gdir = pos ;
}


Unfortunately, I still get errors when I compile maxdb. :-( I wrote
another email because it seems to be a different problem.

- Chris


On Fri, 2006-08-11 at 10:33, Dittmar, Daniel wrote:
> >Error while executing "[...]/pgm/ptoc -qn -e -DDYNAHASH vpr01.p"
> >message: No such file or directory
> > at [...]/bin/comppc.pl line 147
> >
> >It turns out the reason is that ptoc tries to use pgenc, which it
> >expects at the location /usr/lib/pgenc. I have installed my devtools in
> >a non-standard directory because I cannot compile it as root, so pgenc
> >is not in /usr/lib.
> 
> The code that should set the location of pgenc is in
> sys/src/base/prot/ptoc/ptoc.c, line 721.
> 
> static  init_globals ()
> {
>     if ( getenv ("TOOL") )
>     {
>  	sete ( &pcomp   , "lib/pgenc") ;
>  	sete ( &how_pc  , "lib/how_pc") ;
> 
> 	/* already defined
> 	 * char    *cpp    = "/lib/cpp";
> 	 * char    *as     = "bin/as";
> 	 */
>     }
> }
> 
> If $TOOL isn't defined, then the default /usr/lib/pgenc (line 73) is
> kept. I can't really imagine that $TOOL isn't set as a whole bunch of
> other script requires that variable.
> 
> Or do you use some very new compiler that doesn't overwrite string
> literals? (what sete () seems to do). But then I would expect a bus
> error, not a silent no-op.
> 
> Perhaps you can add a trace to ptoc.c to make sure if $TOOL exists. If
> it doesn't, maybe you can add traces to comppc.pl just before the call
> to ptoc if $TOOL is set there.
> 
> Daniel Dittmar


-- 
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=sapdb-general@progressive-comp.com

[prev in list] [next in list] [prev in thread] [next in thread]