This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
bug or error in the program
- To: egcs-bugs at cygnus dot com
- Subject: bug or error in the program
- From: Jinpeng Xie <xie at nu dot cs dot fsu dot edu>
- Date: Wed, 30 Sep 1998 15:51:30 -0400 (EDT)
Sir,
I get a very strange problem. I can not figure out.
I attached testcplus.cpp and README. testcplus reads README line by
line and store it in char **array, then outputs char **array to
to screen. I run g++ -o testcplus testcplus.cpp to compile it.
I use "array = new char *();" to allocate memory first,
for each line, I use "array[i] = new char[length]" to allocate memory.
1. testcplus.cpp can run on Solaris 2.6 after compiling by g++.
I cited the output from g++ -v from Solaris 2.6 as follows:
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs
gcc version 2.8.1
2. if testcplus.cpp run on Redhat 4.2, first few lines of output are
garbage, then we can get expected outputs. Finally it goes to crash.
I cited the last few lines of output as follows:
==========================================================================
Use the script 'cleanlog' to remove these files. 'cleanlog'
also checks for core files.
------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x400ac49d in __libc_free ()
(gdb) where
#0 0x400ac49d in __libc_free ()
#1 0x4003b814 in __DTOR_END__ ()
#2 0x8052488 in ?? ()
#3 0x656d616e in ?? ()
Cannot access memory at address 0x656c6966.
=========================================================================
RedHat 4.2 have installed 2.7.2.1 g++. Output of g++ -v is given as
follows:
Reading specs from /usr/lib/gcc-lib/i386-linux/2.7.2.1/specs
gcc version 2.7.2.1
3. testcplus can not run on Redhat 5.1 after I updated g++ to egcs 1.1
release [Reading specs from
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)].
or before I updated [old version is: Reading specs from
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.90.27/specs
gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)].
However, after I truncate README to 25 lines, testcplus runs very well.
--Jinpeng
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
* *
*Jinpeng Xie Office Phone:(850)-487-0054 *
*Dept. of Computer Science Office: Dept. of Management Service*
*Florida State University E-mail: xie@cs.fsu.edu *
* *
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
#include <string.h>
#include <iostream.h>
#include <fstream.h>
int readFileToarray(char **array, int &num);
main()
{
int num=0, i;
char **array;
array = new char *();
readFileToarray(array, num);
for (i=0; i<num; i++) {
cout << array[i] <<endl;
}
}
int readFileToarray(char **array, int &num)
{
int len;
char temstr[200];
fstream file;
file.open("README", ios::in);
while(1) {
if (file.fail()) break;
file.getline(temstr, 199);
len = strlen(temstr);
array[num] = new char[len+1];
strcpy(array[num], temstr);
num++;
}
file.close();
}
##################################################################
AUTOMATED LIBRARY SYSTEM -- SERVER COMPONENT
Copyright (c) 1996, 1997 Florida State University
All rights reserved.
##################################################################
INITIAL NOTES
##################################################################
This documentation and software reflects the installation of
the software on a Linux system. If you are installing the
software in another environment, you must make appropriate
changes on your own.
##################################################################
OVERVIEW
##################################################################
The automated library system server component consists
of a set of C-shell scripts and C programs that together
accomplish the tasks of indexing and building HTML pages
to provide access to metadata records and documents.
Metadata records are transmitted into the system through
electronic mail or FTP. Each metadata record is accompanied
by a field within the metadata record that informs the
system what transaction should be performed on that entry
(add, delete, update).
Following security checks, C-shell scripts and C programs
begin the process of adding the metadata record into the
repository. Each record *must* have a unique identifier.
The identifier of the record is specified by the RECID field
within the metadata record.
The metadata record is (1) indexed, and (2) linked to any
accompanying documents. There are several types of indexes
(see below). All indexes and pointers to the indexes are
constructed automatically.
##################################################################
INSTALLATION
##################################################################
Installation involves (A) compiling the source programs for
your system and (B) modifying the appropriate control files
for the shell scripts and programs.
--- create a new loginid just for this server. The
C-shell scripts are designed to reference files
and directories by $HOME and the loginid by $USER.
This loginid must be able to accept email messages.
--- add the $HOME/bin directory to the ~als user's
.login path
--- uncompress and untar the package to create the
directory structure for the system. A special and
separate loginid for the server *must* be defined.
That is, the highest level HTML file for the server
should be accessible in the following ways:
local: $HOME/public_html/index.html
remote: http://yoursite/~<login id>
Since the server has its own loginid, it therefore has
*and must have* its own mailbox. Electronic mail is
another method of user submission.
--- make all source programs
cd ~als/src
make
The Makefile uses the GNU gcc compiler. Hopefully,
you will have little or no changes to make in order
to compile and install the software.
--- set permissions
cd $HOME/public_html
chmod a+r *
cd $HOME/bin
chmod a+rx *
chmod go-x *
--- change the owner and group of the Z39.50 server
cd ~als/bin
su root
chown root zserver
chgrp root zserver
chmod a+rx zserver
chmod a+s zserver
exit
--- create an incoming ftp directory owned and accessible
by the server programs. The directory should have
the permissions rwx-wx-wx . WARNING! This directory
should be an incoming directory only. The software
is designed to destroy/remove *all* files in that
directory during each processing cycle.
--- modify the file $HOME/public_html/GLOBALS to
specify the correct email addresses, directory paths,
and URL for the web site
--- modify the file $HOME/public_html/BASE.sty so it
contains the default style sheet for all submissions.
Add or modify all other style and formatting sheets
(.rpt files) to meet your requirements.
Style sheets are simply HTML pages that contain the
two special comment lines
<!-- startbody -->
<!-- endbody -->
These lines are used by the indexing and page-building
programs to identify where in the style sheet
information should appear.
--- modify the $HOME/public_html/index.html file to
provide the look and feel you want on your home page.
WARNING... this file **MUST** contain the comment
lines
<!-- startbody -->
<!-- endbody -->
within it, as per the supplied file. These lines are
used by the indexing programs to identify where in the
file entries can be added.
##################################################################
OPERATION
##################################################################
The system operates by invoking a set of C-shell scripts
and programs in a hierarchical manner. Here is the order
of execution:
wb-start
wb-loop
wb-getwork
wb-dowork
wb-add or wb-delete
pr_* programs
DO NOT try to run the system by executing 'wb-loop' directly.
The "wb-loop" C-shell script is run as a background job. It is the
only element of the system that runs on a regular basis. This script
monitors the FTP site and email box for submissions. When a new
entry arrives, wb-loop begins the process of cataloging the record.
Note, wb-start runs the system by nice'ing it at a lower priority.
It is not necessary to run the system at a higher priority.
To stop the system:
cd ~als/bin
wb-stop
##################################################################
Z39.50
##################################################################
Z39.50 services are provided by the USGS/CNRI 'zserver' program.
This program resides in the ~als/bin directory. The program runs
as a root level process in order to use the standardized port 210
for Z39.50 connections.
The zserver software requires several files in the ./public_html
directory. These files include 'sapi.ini', 'zserver.ini',
'GetScript', 'SearchScript', and all of the ISEARCH.* files.
When a metadata record arrives for cataloging, the record is
actually indexed two different ways. It is indexed in the
ALS system using a technique that provides access through the
WWW. The record is also indexed using the pr_met2sgml program
and USGS Iindex program. A set of files beginning with the
prefix ISEARCH. are created in the public_html directory.
It is upon this set of files that zserver respondes to
Z39.50 queries.
When a metadata record is updated or delete, all metadata files
are reindexed using the Iindex program. That is, a complete
replacement of all ISEARCH.* files occurs. This is as per a
suggestion in the USGS documentation to improve performance.
The zserver software requires the existence of the ISEARCH.*
files. After cataloging your first record, run zserver as
a background process. In fact, it is suggested that you add
an entry to your boot files (/etc/rc.d/...) to automatically
start zserver whenever the system is rebooted.
##################################################################
SECURITY
##################################################################
Transactions are sent to the server through electronic mail
and ftp. There are two methods that security is enforced:
-- tight -- requires incoming transactions contain
an electronic signature field
-- loose -- requires incoming transactions contain
a valid email address
TIGHT SECURITY METHOD.
If the file $HOME/bin/ESIG exists, the system will enforce
tight security. When a transaction is submitted, the
submitting metadata software will compute an "electronic
signature" from the RECID, RECTYPE, and PASSWORD fields
provided by the user. A long string of digits will result
and be stored within the metadata record.
When the metadata record arrives at the server, the software
will extract the field CATALOGERID from the record and use
this field to locate a $HOME/bin/AUTHUSER.xxxxx file. From
that file the software will extract the user's password, and
recompute the electronic signature at the receiving end. If
both electronic signatures match, the record will be
accepted. If the signatures do not match, the record will
be rejected.
LOOSE SECURITY METHOD.
The "pr_security" program checks to make sure
-- the program "pr_check_mailfile_for_rejects" checks
all incoming email submissions for illegal entries.
For example, the program looks for the GOOD TIMES virus
and will allow you to trash email from certain locations.
The file $HOME/bin/REJECT defines what should be
deleted.
-- a transaction arrives from a 'valid' email address
-- the WHATTODO field is valid (add, delete, update)
-- a metadata file exists (".met" or ".MET")
-- for ftp'd arrivals, the package must be tar'd
and the file name must end with .tar or .TAR
-- a valid and unique object/metadata record identifier
is specified in the RECID or OID field of the metadata record
##################################################################
DAY TO DAY MAINTENANCE
##################################################################
Activities on the server run mostly automatically, there
really is little maintenance to do unless something goes
haywire. The main focus of maintenance is on:
-- add/delete/update submitting users (use the ./bin/adduser
and ./bin/deleteuser programs for this activity)
-- look through the $HOME/bin/LOG* files for core
dumps and/or failed transactions (use the ./bin/cleanlog
script to remove LOG files and check for core files)
-- browse the repository on a regular basis to look for
security violations or bogus records. Sometimes
a bogus record will occur because a user has submitted
a metadata record that is too large or contains
corrupted (non-ASCII) data.
-- browse links from metadata records to look for
inappropriate images, text files, or other materials
(some of this could be automated)
##################################################################
DIRECTORIES
##################################################################
public_html
This directory serves as the "root" of the WWW tree on
the server. The file "index.html" in this directory is
the root file. The installation version of the
index.html file provides a basic header and links to
forms and cgi programs that support queries and map browsing.
The important thing to remember is that inside the
"index.html" file there are two comment lines that
contain the words "startbody" and "endbody". The
programs that build the repository automatically key off
of these two words, using them as outer boundaries of
links to the various libraries.
src
The "Makefile" makes all programs and copies them into
the appropriate directories to support execution of the
server.
bin
A more complete description of all files in this directory
is provided below.
##################################################################
$HOME/bin directory
##################################################################
------------------------------------------------------------------
filename = "wb-start"
Starts the cataloging system.
------------------------------------------------------------------
filename = "wb-stop"
Stops the cataloging system.
------------------------------------------------------------------
filename = "AUTHUSER.xxxxx"
A separate file is created for each authorized user. It contains
the user's email address, name, and organization. Here is an
example:
USERNAME M. Mouse
USEREMAIL mmouse@disney.orlando.florida.org
The fields USERNAME and USEREMAIL are the only required fields.
The programs ./bin/adduser and ./bin/deleteuser maintain the
authorized user files.
------------------------------------------------------------------
filename = "REJECT"
A file used by the "pr_check_mailfile_for_rejects". This
program scans the mail file for the server looking for illegal
messages (e.g., GOOD TIMES virus, a message from a particular
user). Whenever an entry of this type is found it is removed
from the mail file and copied into the $HOME/rejects directory.
------------------------------------------------------------------
filename = "HIDDENFIELDS"
A list of fields that should not be indexed or cataloged by
any program.
------------------------------------------------------------------
filename = "STOPLIST"
A list of words that should be ignored when building the
inverted index (pr_invindex program).
------------------------------------------------------------------
filename = "maint-delete"
Run this script from the public_html directory to delete a
metadata record. As follows:
cd $HOME/public_html
maint-delete xyz.met
------------------------------------------------------------------
filename = "maint-update-system"
Run this script from the ~als directory. It will retrieve the
last version of the software from the ALS development site
and install the software updates on your system automatically.
------------------------------------------------------------------
filename = "wb-recat"
Rarely used. Run from the public_html directory to completely
recatalog a record or several records.
------------------------------------------------------------------
filename = "LOG*"
A sequence of files, one for each day, that contain a
processing log for everything processed by the server.
This is a good place to start looking for problems should
they occur.
Use the script 'cleanlog' to remove these files. 'cleanlog'
also checks for core files.
------------------------------------------------------------------