Pb compiling on hpux 11i a gnu tool

[Mme Jonnaert]

HI,
Please,Someone can help us?
We use torque for many years and it's a very nice tool but this time we don't find the problem
thanks


________________________________
De : JONNAERT Therese Marie
Envoyé : mercredi 30 septembre 2009 11:34
À : 'torquedev at supercluster.org'
Objet : again: help,problem to install torque 2.3.7 on hp itanium 11iv23

[cid:943493109 at 30092009-178D]

hi,

To day we use the 2.1.8 torque on our systems and we want to upgrade to the 2.3.7 version.

We have configure the package with these options:

./configure --disable-gui --with-server-home=/sas/torque CFLAGS=+DD64

because with the standard CFLAGS , the hpux32 library were used, and it doesn't work.But after the make and make install, when we try to initialize the pbs_server database with have a core dump-(memory fault)

So, here is the result of the gdb result:

ts1cpl1h(root)/opt/cofidis/torque/torque-2.3.7> gdb pbs_server

HP gdb 5.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.

Copyright 1986 - 2001 Free Software Foundation, Inc.

Hewlett-Packard Wildebeest 5.0 (based on GDB) is covered by the

GNU General Public License. Type "show copying" to see the conditions to

change it and/or distribute copies. Type "show warranty" for warranty/support.

..

(gdb) run -t create

Starting program: /usr/local/sbin/pbs_server -t create

Program received signal SIGSEGV, Segmentation fault

si_code: 2 - SEGV_ACCERR - Invalid Permissions for object.

0x87ffffffef744dc0:0 in mk_log_name (

pbuf=0x87ffffffffffd7e0 "\207\377\377\377") at ../Liblog/pbs_log.c:200

200 sprintf(pbuf, "%s/%04d%02d%02d",

(gdb) where

#0 0x87ffffffef744dc0:0 in mk_log_name (

pbuf=0x87ffffffffffd7e0 "\207\377\377\377") at ../Liblog/pbs_log.c:200

#1 0x87ffffffef7450f0:0 in log_open (filename=0x0,

directory=0x6000000000025310 "/sas/torque/server_logs")

at ../Liblog/pbs_log.c:264

#2 0x4000000000060420:0 in main (argc=3, argv=0x87ffffffffffed38)

at pbsd_main.c:1109

(gdb)

Can you help us?

thanks

therese-marie

[Andre-Marcel Hellmund]

Hey Therese-Marie,

if sprintf() fails with SIGSEGV, I would assume that pbuf (char *) is NULL, any other invalid address or that the buffer pbuf points to is to short to hold the character string.

You could verify with

(gdb) p pbuf

If that does not work you should possibly compile the executable with -g to enable debugging information.

If my assumption is true, you should then check the source code of mk_log_name and check if pbuf is really allocated.

[Dennis Handly]

Have you printed the values passed to sprintf?
And you have 4 more of them?

Is pbuf large enough to contain the first string parm? And as Andre-Marcel asked, is pbuf valid?

>Andre-Marcel: I would assume that pbuf (char*) is NULL, any other invalid address

gdb is printing pbuf in the stack trace.

>you should then check the source code of mk_log_name and check if pbuf is really allocated.

Since it is probably a parm, you will have to look at the caller log_open.

[Andre-Marcel Hellmund]

> gdb is printing pbuf in the stack trace.
> Since it is probably a parm, you will have to look at the caller log_open.

Yes, you are of course correct. I was missing this. I was just looking at the sprintf() call ...