Re: Sedit Problem

From: Todd A Laycock (
Date: 07/29/01

On Sat, 28 Jul 2001, Timbrewolf wrote:

> To recreate the crash error, use sedit.  *grin*  Okay, for my test to make
> sure it wasn't just my code, I downloaded Circle3.0 bpl18 and Oasis 2.0
> (also tried with 2.01) and patched it in.  No other patches.
> Go into sedit for a shop (you can use a standard midgaard shop), change the
> shopkeeper (even to the same one), change a couple things (product list,
> etc. you can use the same info) and exit.
> It should save internally just fine, but if you sedit save and try to do a
> 'show zones' it will crash without an addition to the log.  If you go into
> your /lib/world/shp files, it will probably be corrupt (stray high ascii
> chars randomly on the shop you edited).  Then, if you delete just the shop
> that caused the problem, everything should run fine.  So I'm unable to use
> sedit at all.

I came across this last symptom (stray high ascii chars) in sedit myself.
The problem was in genshp.c in copy_shop, and add_shop.

In copy_shop I commented out the line "free_shop_strings(tshop);".
In add_shop I added "free_shop_strings(&shop_index[rshop]);" just before
the copy_shop call in the already exists if statement:

   * The shop already exists, just update it.
  if ((rshop = real_shop(S_NUM(nshp))) != NOWHERE) {
    copy_shop(&shop_index[rshop], nshp);
    if (rznum != NOWHERE)
      add_to_save_list(zone_table[rznum].number, SL_SHP);
      mudlog("SYSERR: GenOLC: Cannot determine shop zone.",
             BRF, LVL_BUILDER, TRUE);
    return rshop;

The reason for the stray ascii chars (I think), is further down in
add_shop.  The for loop that looks for the insertion point for the new
shop contains the line: "shop_index[rshop] = shop_index[rshop - 1];" which
copies the pointers for the strings of the previous shop.  When copy_shop
is finally called, either in the for loop or in the !found if statement,
it tries to free those pointers because they're still in the destination
shop's memory.  However they're also still being used by where the
destination shop was copied to.  So when those strings are freed, the shop
is pointing to freed memory, which if it doesn't crash right away,
displays garbage characters like that.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST