1. check this please???
Okay, I am having a tough time with this segmentation error problem.
To test something I wrote a very simple allocate and free program, I
am using safe.e in place of machine.e to test it with. This little
program
written on a linux (SuSe) platform caused a segmentation fault. Anyone
have a clue??
with trace
trace(1)
procedure main()
atom data
data = allocate(8)
free(data)
end procedure
main()
What exactly am I doing wrong here? This is a microcosm of the heart of
my world.
2. Re: check this please???
On Fri, 18 Aug 2000 12:36:06 -0400, Paul <draegur at WSERV.COM> wrote:
>Okay, I am having a tough time with this segmentation error problem.
>To test something I wrote a very simple allocate and free program, I
>am using safe.e in place of machine.e to test it with. This little
>program
>written on a linux (SuSe) platform caused a segmentation fault. Anyone
>have a clue??
>
>with trace
>trace(1)
>procedure main()
> atom data
> data = allocate(8)
> free(data)
>end procedure
>
>main()
>
>What exactly am I doing wrong here? This is a microcosm of the heart of
>my world.
What value is data returning ?
Try declaring variable data outside the function and see if
that makes any difference.
Try allocate_low see if that makes any difference.
If that works you may have a bad memory chip.
Try running on a different PC.
These are just ideas to try.
Bernie
3. Re: check this please???
In a message dated 8/18/00 12:42:59 PM Eastern Daylight Time,
draegur at WSERV.COM writes:
<< What exactly am I doing wrong here? This is a microcosm of the heart of
my world. >>
heh... I'm making a game called Microcosm Worlds... 
Just thought i'd add
that since you used both words... =)
~later~
4. Re: check this please???
>
> >with trace
> >trace(1)
> >procedure main()
> > atom data
> > data = allocate(8)
> > free(data)
> >end procedure
> >
> >main()
> >
> >What exactly am I doing wrong here? This is a microcosm of the heart of
> >my world.
>
> What value is data returning ?
data = 13473656 (just a pointer I am assuming)
>
>
> Try declaring variable data outside the function and see if
> that makes any difference.
>
no difference
>
> Try allocate_low see if that makes any difference.
> If that works you may have a bad memory chip.
Allocate_low doesn't work on linux platforms
>
> Try running on a different PC.
>
Two different ones (one running Redhat and the other SuSe
>
> These are just ideas to try.
>
> Bernie
Just answering these to hopefully give more information to anyone reading
this thread.
Thanks Bernie!
5. Re: check this please???
What happens when you use safe.e?
>>> draegur at WSERV.COM 08/18/00 01:39PM >>>
>
> >with trace
> >trace(1)
> >procedure main()
> > atom data
> > data = allocate(8)
> > free(data)
> >end procedure
> >
> >main()
> >
> >What exactly am I doing wrong here? This is a microcosm of the heart of
> >my world.
>
> What value is data returning ?
data = 13473656 (just a pointer I am assuming)
>
>
> Try declaring variable data outside the function and see if
> that makes any difference.
>
no difference
>
> Try allocate_low see if that makes any difference.
> If that works you may have a bad memory chip.
Allocate_low doesn't work on linux platforms
>
> Try running on a different PC.
>
Two different ones (one running Redhat and the other SuSe
>
> These are just ideas to try.
>
> Bernie
Just answering these to hopefully give more information to anyone reading
this thread.
Thanks Bernie!
6. Re: check this please???
Mike Sabal wrote:
> What happens when you use safe.e?
The segmentation error only occurs when I use safe.e in the small example I
provided. However in my much larger mud server I get the error at random
times that I am not able to track down easily. (I began using safe.e when
Mr. Craig suggested it in a post a few days back)
The segmentation error simply halts everything. There is, of couse, no
ex.err file generated nor is there any other information provided. I am
just hoping that if I can figure out why this small program has an error I
can start looking deeper into my mud server.
7. Re: check this please???
Paul wrote:
> Mike Sabal wrote:
>
> > What happens when you use safe.e?
>
> The segmentation error only occurs when I use safe.e in the small example I
> provided. However in my much larger mud server I get the error at random
> times that I am not able to track down easily. (I began using safe.e when
> Mr. Craig suggested it in a post a few days back)
> The segmentation error simply halts everything. There is, of couse, no
> ex.err file generated nor is there any other information provided. I am
> just hoping that if I can figure out why this small program has an error I
> can start looking deeper into my mud server.
Also note that the error occurs in the process free() in safe.e when
the code executes the line:
machine_proc(M_FREE, a)
(sorry to be flooding the list guys)
8. Re: check this please???
Paul writes:
> Okay, I am having a tough time with this segmentation error problem.
> To test something I wrote a very simple allocate and free program, I
> am using safe.e in place of machine.e to test it with. This little
> program written on a linux (SuSe) platform caused a
> segmentation fault. Anyone have a clue??
> include safe.e -- I assume you included this -- Rob
> with trace
> trace(1)
> procedure main()
> atom data
> data = allocate(8)
> free(data)
> end procedure
It crashed on my Red Hat system too.
You've found a bug in safe.e.
All users of safe.e should change the line in
global procedure free() in safe.e (*not* machine.e!)
that reads:
machine_proc(M_FREE, a)
to instead read:
machine_proc(M_FREE, a - BORDER_SPACE)
The bug doesn't show up under WATCOM because
WATCOM's storage allocator does very little on a free()
operation, just setting a bit. GNU C probably tries to
combine adjacent free blocks. WATCOM does the combining
during the malloc(). I think it will simply fail to actually free the
block.
Paul: after fixing safe.e, continue running your large application.
If you are lucky, safe.e will now find your bug. And thanks for
reporting this safe.e bug.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: check this please???
Ha HA!
Works like a charm and I think I am on my way to tracking down the
segmentation fault error!
You da man Rob!
10. Re: check this please???
Some further checking shows that free_low() in safe.e
contains the same bug as free().
In global procedure free_low() in safe.e
Change:
machine_proc(M_FREE_LOW, a)
to:
machine_proc(M_FREE_LOW, a-BORDER_SPACE)
Note that machine.e is ok. I'm just talking about safe.e,
the debugging version of machine.e.
On Linux or Windows free_low() isn't used,
but on DOS the block of low memory will
not actually be freed without this fix. These
fixes will be in the next release.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
