Very Computer

I've been writing some basic graphics programs under Linux 2.0 using
g++ and libgrx (the Linux port of the djgpp graphics library). I get
random segmentation faults with my programs. Sometimes they segfault
when they exit, sometimes the segfault when they start. The behaviour
is consistent for any particular program, but if I change it around a
little (add debugging cout << lines, for example), the behaviour can
change.

I haven't noticed such problems when I build applications without
libgrx, so that seems likely to be the problem. Furthermore, the example
program cliptest from the Grx package compiled with gcc works fine, but
when compiled with g++ it segfaults on exit, which leads me to believe
that there is a problem in the interaction between libgrx and g++.

Does anyone have any ideas on how I can track down the problem and fix
it?  Here are the details of my setup:

Linux 2.0.7
libc 5.3.12
libg++ 27.1.4
gcc 2.7.2
ld.so 1.7.14
libgrx 1.0.4 from sunsite

Thanks,
Ed

--
--

 "Being on time is like being on fire."

Folks,
    I'm trying to understand this puzzle:
    Below is c++ program that will fail with `Memory fault'
----------------------------------------------------------------------
extern "C" {
#include <netdb.h>

Quote:}

extern int h_errno;

main()
{
    struct hostent *hp;
    char *host="darkstar";

    hp = gethostbyname(host);
    cout << "official host name: "; // << hp->h_name << endl;

Quote:}

main()
{
    struct hostent *hp;
    char *host="darkstar";

    hp = gethostbyname(host);
    printf("host name: %s\n", hp->h_name);

Quote:}

System
------
Linux darkstar 1.3.79 #1 Mon May 20 21:42:05 GMT 1996 i586
gcc version 2.7.0
libg++.so.2.7.0
libstdc++.so.2.7.0
libc.so.5.0.9
libm.so.5.0.0

    I've just start using C++, so, please, if anyone can point
    out my mistake, I will appreciate it. If possible, reply by
    mail.

Hans-Bernhard Broeker (Aachen, Germany)

On 5 Aug 1996 12:44:38 GMT, Hans-Bernhard Broeker
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

However, if I just let the program run under gdb, the segfaults always
occur in __libc_free. The Linux libc 5.3.12 free() is quite demanding;
many programs broke because they would malloc, modify the pointer
returned, and free the modified pointer, which was acceptable under libc
5.2 and earlier. Perhaps that is the problem.

I've been trying to track down all the free()s in libgrx to see if any
of them free modified pointers, but it's quite time consuming work.
Hopefully I'll have more information in a few days. In the meantime,
other suggestions are most welcome.

Ed

--

 "Being on time is like being on fire."

Quote:> I've been trying to track down all the free()s in libgrx to see if any
> of them free modified pointers, but it's quite time consuming work.
> Hopefully I'll have more information in a few days. In the meantime,
> other suggestions are most welcome.

% gcc -DDEBUG -c /usr/src/libc/dl-malloc.c

and then link dl-malloc.o statically into your application.  This way
you have a much better chance of spotting the problem where it
actually occurs.

There are other more heavy-weight methods to find these problems,
like ElectricFence and Checker.

Regards,
Wolfram.

Hi all,

gcc 2.7.2 has a bug where __attribute__ ((packed)) is not
correctly handled in x.cc code (g++), but is correctly handled in
x.c (gcc) code. This used to work in 2.7.0 g++, where we developed
a bunch of c++ code using this attribute.

I'd really like to upgrade the compiler to 2.7.2, mainly because I
want to use libc >= 5.2.18. I believe that use of these later
libraries requires use of 2.7.2 (library release doco says
something along these lines). Does anyone know of a way to get the
packed attribute to work, without completely re-writing all code
accessing these packed structures to use access methods written in
c? Alternatively, can anyone tell me whether I can safely use the
later libraries with gcc 2.7.0 (the release notes suggest not)?

Am I asking for the impossible?

Mike