"Erwin S. Andreasen" <erwin@pip.dknet.dk> writes:
> > I like this idea... I think I'll look into implementing it on my
> > codebase. Would it be possible to make a dropfile, ".badshared" that,
> > if present, the code won't re-use the shared memory? Always make this
> > file as one of the first things, then remove it if the shared memory
> > data passes some kind of validity check.
>
> Well, how to detect when is the shared memory not valid? Set a dirty flag
> each time before modifying it and clear it afterwards?
Nah, detect it bad by crashing. It would break the crash
loops... however, more subtle corruption issues might not be so easily
avoided. Setting a bit would work fine as well. Can mprotect be used
on shared memory regions?
Hmm just thought of something regarding stack overruns. Perhaps it
would be possible to use mprotect as something of a buffer? Perhaps
in game_loop, make a 4k char array and mprotect it. That would help
things that overwrite large portions of the stack... but it wouldn't
solve it completely. I wonder if this would be effective?
Another option would be to make a special allocator function that
returns a block of memory with the top and bottom 4k (ie page size on
x86's) protected with mprotect. That would ensure against buffer
overruns/underruns (at least decent-sized ones). Only problem would
be free() would have to take these into account. I think glibc2 has a
number of functions in the malloc family that can help get info on a
block (including the pointer to the beginning of a malloc'd block).
A great site for the full glibc2 documentation (as well as all other
GNU products) is
http://www.delorie.com/gnu/docs/
Of course, real men use info *grin* (these docs are updated regularly
and are texi2html'd from the original info files).
> What I do BTW, is to have functions to acquire a "named" data area in the
> shared memory and use that as the list head for something like notes etc.
I've never used any of the shm* functions before, and as I mentioned,
my APUE got purloined long ago. Can you post some sample code, or
perhaps a url to more information? The man pages are somewhat lacking
in explaining general use (though very detailed in the myriad of options).
> Sorry, I don't know of an online reference. Stevens APUE is indeed where I
> saw this. Maybe you could look at the Open Group's page
> (www.opengroup.org) - they have complete man pages that you can comment on
This is a very nice site. They do indeed seem to have a wide
assortment of info available. I've not finished perusing it yet so I
don't know how much they have beyond man pages though.
> Actually, the man attributes(5) page also contains a complete list of the
> async-signal-safe function, so you can look at that if you have a Sun
> machine near you (what you are using now seems Linuxish :)
Very Linuxish, and happily so :) *hopes to move to an Alpha-based
Linux platform next upgrade, whenever that may be*
> Alternative, you could stuff that info into a small block of shared
> memory, avoiding disk writes. The could should be simple enough so that is
> safe.
Definitely more efficient. That or use mmap (which I am more familiar
with than the shm* functions).
> Strangely, abort worked poorly for me - perhaps because I called it from a
> signal handler.
It worked for me in my linux box, but I've changed it to a simple
return instead. Should work the same, and I don't want anything to
pop up at a later date.
> Also a checkpoint, that prints current function name, __FUNCTION__ into a
> buffer. I used to have some sprintf overflow some obscure place, which I
> finally found by turning sprintf into a macro that save the format string
> and file/line onto that buffer before doing the real sprintf. that slows
> the MUD down quite a bit, but found the bug.
__FUNCTION__ is I believe a gcc extension... though not an issue on
Unix boxes I imagine (and I expect other platforms have copied it as
well).
> PS: Anyone know what Descriptor::._53::~._53(void) is supposed to be? nm
> will not demangle it, and I have an undefined reference to it, and I can't
> locate the demangling reference for gcc - the unmangled name is
> _._Q210Descriptor4._53.
No idea on this one. Maybe revert a version, see what was changed?
Looks like a destructor of some sorts, but I assume you already knew
that.
It could be a libg++ issue. Have you upgraded compilers or libraries?
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerjh/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST