From: Mike Rusch <ruschtmm AT newnorth DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: keyword "new" causes SIGSEV
Date: Mon, 24 Aug 1998 15:08:34 -0500
Organization: CentWis Computing
Lines: 108
Message-ID: <35E1C842.45EFF366@newnorth.net>
Reply-To: ruschtmm AT newnorth DOT net
NNTP-Posting-Host: ribl1-cs-4.newnorth.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

In my program, I define a structure reptfmt as follows:

struct reptfmt {
    char numfields;
    char numsorts;
    char **fnames;
    fieldinfo *fields;
    sortinfo *sorts;
    char groups;
} ;

Sometimes I need a copy of a reptfmt structure.  Since var1 = var2
doesn't make copies of the data pointed to by fnames, fields, and sorts,
I had to write a special function called "reptfmtcpy":

void reptfmtcpy(reptfmt &dest, const reptfmt src) {
    dest = src;

    dest.fields = new fieldinfo[dest.numfields];
    dest.fnames = new (char *)[dest.numfields];
    if(dest.fields != NULL && dest.fnames != NULL) {
        for(int i = 0; i < dest.numfields; i++) {
            dest.fields[i] = src.fields[i];
// ---THE NEXT LINE IS LINE 1292---
            effstrcpy(dest.fnames[i], src.fnames[i]);
        }
    }
    dest.sorts = new sortinfo[dest.numsorts];
    if(dest.sorts != NULL)
        for(int i = 0; i < dest.numsorts; i++)
            dest.sorts[i] = src.sorts[i];
}

The first line copies numfields, numsorts, and groups.  The rest copies
all the stuff that is pointed to.  The function effstrcpy() (which I
wrote) allocates memory for the first string, then does a strcpy:

char *effstrcpy(char * &dest, const char *src) {
// ---THE NEXT LINE IS LINE 76---
    dest = new char[strlen(src) + 1];
    if(dest != NULL) strcpy(dest, src);
    return dest;
}

When I run the program and get to a point where reptfmtcpy is used (in
function formatnew(), I get a SIGSEV:

  0x0000c8d0   _malloc+192
  0x000085f8   ___builtin_new+44, line 65535 of libgcc2.c
  0x000085b3   ___builtin_vec_new+11, line 65535 of libgcc2.c
  0x0000747a   _effstrcpy__FRPcPCc+26, line 76 of effio.cpp
  0x00004eed   _reptfmtcpy__FR7reptfmtG7reptfmt+269, line 1292 of
collegdb.cpp
  0x00006ceb   _formatnew__Fv+75, line 1801 of collegdb.cpp
  0x00006b99   _format__Fv+421, line 1758 of collegdb.cpp
  0x000082a2   _Show__7MenuBari+1094, line 328 of menusys.cpp
  0x00001723   _main+387, line 95 of collegdb.cpp
  0x0000ae82   ___crt1_startup+138 

Now, this doesn't happen right away.  Everything works fine in
reptfmtcpy until i = 7.  I have no idea why it doesn't work at 7.  There
are 17 members of the array.  I can print src.fnames[7], and
strlen(src.fnames[7]) just fine.  Plus, at one time I broke up the
statement into pieces so that the strlen call was separate.  strlen
worked fine, but new didn't.

Other info you may want:
Output of go32-v2:
DPMI memory available: 10891 Kb
DPMI swap space available: 1373 Kb

Environment vars:
TMP=C:\WINDOWS\TEMP
TEMP=C:\WINDOWS\TEMP
PROMPT=$p$g
winbootdir=C:\WINDOWS
COMSPEC=C:\WINDOWS\COMMAND.COM
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\SYSTEM;C:\;C:\DJGPP\BIN;C:\DJGPP\RSXNTDJ\BIN;G:\LEARN_C
INCLUDE=g:\learn_c\include
DJGPP=C:\DJGPP\DJGPP.ENV
RSXNTDJ=C:\DJGPP\RSXNTDJ
windir=C:\WINDOWS
BLASTER=A220 I5 D1 H5 P330 T6
CMDLINE=colleges

AUTOEXEC.BAT:
@loadhigh C:\WINDOWS\COMMAND\SHARE.EXE /l:500 /f:5100
path =
c:\windows;c:\windows\command;c:\windows\system;c:\;c:\djgpp\bin;c:\djgpp\rsxntdj\bin;g:\learn_c
set include=g:\learn_c\include
set DJGPP=C:\DJGPP\DJGPP.ENV
set RSXNTDJ=C:\DJGPP\RSXNTDJ
verify off
choice /c:yn /t:n,02 Do you want to clear the TEMP directory?
if not errorlevel 2 del c:\windows\temp\*.*

(No CONFIG.SYS)

So, what do I do?  From the traceback it almost looks like "new" calls
malloc, but this seems strange to me since new is supposed to be a
keyword, and supposedly more efficient than malloc.  I suppose I could
use malloc instead, but then I'd have to change all my new's to malloc's
and my delete's to free's.  Plus, who knows if malloc would work any
better?

If anyone can help me get rid of this error, I'd really appreciate it.

Mike.