Home   News   Concept   AMIGA-Compatible   Hardware   Forum   Questions+Answers   Pictures   Contact & Team

Welcome to the Natami / Amiga Forum

This forum is for AMIGA fans interested in the new NATAMI platform.
Please read the forum usage manual.


All TopicsNewsQAFeaturesTalkTEAMLogin to post    Create account
Do you have questions about the Natami?
Post it here and we will answer it!

Porting Wipeout Help From Chris Or Thomas Welcomepage  1 2 
Bernd Afa
Germany

Posts 146
13 Mar 2010 18:42

I begin now to port wipeout so it can compile with GCC 68k.
  25% i can compile now, by change the AOS specific asm register feature to GCC.
 
  the problem i see for tlsfmem is that wipeout do some check if a a memfree address is really in a allocatet block.it use the memlist
 
  is this need or have tlsfmem maybe a own consistency check for that ?
 
  AROS/AFA memsystem do consistency check, so here this is not need.
 
  also the check if the freemem size fit with the alloc size  check.is there consistency check done in tlsfMem ?
 
  and last not least for the C experts i get a error here.what need i change, that it work.I think wipeout is written with stormc3.
 
  The MOS code is complete diffrent here
 
  STATIC PUTCHAR putChar = SerPutChar;
 
  dprintf.c:28: error: function `putChar' is initialized like a variable
 
  and here
 
  putChar = ParPutChar;
 
  dprintf.c:38: error: invalid lvalue in assignment
 
 
  thats the sourcesnippet
 
 
  typedef VOID (PUTCHAR)(UBYTE c __asm("d0"),APTR putChData __asm("a3"));
 
  /******************************************************************************/
 
  /* these are in rawio.asm */
  extern VOID SerPutChar(UBYTE c __asm("d0"),APTR putChData __asm("a3"));
  extern VOID ParPutChar(UBYTE c __asm("d0"),APTR putChData __asm("a3"));
 
  /******************************************************************************/
 
  STATIC PUTCHAR putChar = SerPutChar;
 
  /******************************************************************************/
 
  VOID
  ChooseParallelOutput(VOID)
  {
    Forbid();
 
    /* use the parallel port output routine. */
    putChar = ParPutChar;
 
    Permit();
  }

Thomas Richter
Germany

Posts 695
14 Mar 2010 22:15

bernd afa wrote:

  I begin now to port wipeout so it can compile with GCC 68k.
    25% i can compile now, by change the AOS specific asm register feature to GCC.
   
    the problem i see for tlsfmem is that wipeout do some check if a a memfree address is really in a allocatet block.it use the memlist
   
    is this need or have tlsfmem maybe a own consistency check for that ?
 

  Bravo! Maybe the best problem to make people understand the problem is to let them run into it.
 
  You just discovered the central problem of all this - it is not a "port", it is a rewrite.
 
  Now, consider a situation where wipeout would actually not even *use* *any* of the memory manager routines patched into exec whatsoever, but would have to use its own routines to begin with.
 
  You would then understand that instead of *not only* rewriting wipeout, you also would need to rewrite the memory patch for a debugging tool.
 
  The net effect of which is a debugging tool which *only* offers you the additional advantage of running after an inofficial patch has been installed, but then not even needing the patch, and not actually running any faster by that. Wouldn't it be easier just to remove the patch in first place?
 
  Oh well...
 
 
bernd afa wrote:

    also the check if the freemem size fit with the alloc size  check.is there consistency check done in tlsfMem ?
 

  I don't know the patch, but under AmigaOs you cannot, unfortunately, depend on this, though it is definitely bad style. Layers below V39 had this issue, they allocated memory in one big chunk and released it piece by piece. It is not illegal, but disregarded - the memory allocator should be able to handle this situation, but a debugging tool should alert the programmer on this.

Thus, such a warning should not go into the patch, but only into the debugging tool.

Concerning your question on the prototype: The line itself might be OK, but this depends on the already defined symbols. It is out of context, and from that hard to judge whether it is correct or not.

STATIC PUTCHAR putChar = SerPutChar;

looks fully correct with the typedef below, provided STATIC is defined to something useful.

Greetings from Edison, NJ. Got stuck here due to the bad weather in Newark. Argh!

Greetings,
Thomas


Bernd Afa
Germany

Posts 146
18 Mar 2010 16:57

>Now, consider a situation where wipeout would actually not even >*use* *any* of the memory manager routines patched into exec >whatsoever, but would have to use its own routines to begin with.
 
  this check_for_address is the only thing.But a replacement for this is to add before the start cookie 1 long that store the size of the alloced mem and a pointer before that, that point to this size long for sanity check.
 
  new wipeout can then look at cookie start -8 for the size and compare that and bring a output that memory with wrong size or address is free.
 
  The allocmem on start for wipeout can do by check for MEMF_LARGEST and then alloc this memblock and fill it with values.
 
  Now alloc as long as you get a size of MEMF_LARGEST all the mem and fill it.
 
  MOS do that
 
  I hope TLSFmem support memflargest.
  If not i need alloc all mem in steps.for example 64 kb.and when no 64 kb mem can get, then get smaller until all mem is alloced and fill with cookie values.
 
  all other things are still system friendly in wipeout.
 
  on malloc
  It alloc a memblock with size + cookiestart+cookieend.
 
  then it fill it with the value and return the mem_block_address+cookie_startsize tothe program.
 
  on free it check bounds and fill the now free mem with teh default values and then free the mem.
 
  STATIC PUTCHAR putChar = SerPutChar;
 
  since nobody know what the problem is, i do it when i fint some time simple and remove the whole output stuff to choose between serial and parallel and i use kprintf.i guess nobody use parallel output.
 

Thomas Richter
Germany

Posts 695
19 Mar 2010 18:37

bernd afa wrote:

    this check_for_address is the only thing.But a replacement for this is to add before the start cookie 1 long that store the size of the alloced mem and a pointer before that, that point to this size long for sanity check.

Have you considered the situation where a program releases memory that does not have this cookie because it is releasing memory that was allocated just *before* the patch was installed?

It's not all that easy, you know...

bernd afa wrote:
 
    STATIC PUTCHAR putChar = SerPutChar;
   
    since nobody know what the problem is, i do it when i fint some time simple and remove the whole output stuff to choose between serial and parallel and i use kprintf.i guess nobody use parallel output.

How can one? Look, if "STATIC" is #define'd to "static" or to an empty string, the definition is all fine. Thus, all you need to do is to find where (or why not) STATIC is #define'd. But since I'm not seeing the whole program (and neither do I like to), nor the error message, and my glass ball is currently misplaced somewhere in Stuttgart, I cannot help much further. Just check for the define, that's all I can guess.

Greetings from Boston (now the MIT),

Thomas



Bernd Afa
Germany

Posts 146
21 Mar 2010 12:45

>Have you considered the situation where a program releases memory >that does not have this cookie because it is releasing memory >that was allocated just *before* the patch was installed?
 
  this must handle by wipeout code(i dont know how it work), because when with installed wipeout a memblock was alloc before it have no cookie and wipeout cant add cookie size and free block as it can do when block is alloced with wipeout install. 
 
  i use now only ser output and below code, then i can compile now 50%.need change all patch code so register syntax of GCC is used, and then i hope it can run....
 
  I try also static, but problem is the same.seem something GCC specific that not allow to put a function address in another pointer
 
 
  when i do
 
  RawDoFmt((STRPTR)format,(APTR)varArgs,(void (*)())SerPutChar,NULL);
 
 

""""
  typedef VOID (PUTCHAR)(UBYTE c __asm("d0"),APTR putChData __asm("a3"));
 
  /******************************************************************************/
 
  /* these are in rawio.asm */
  extern VOID SerPutChar(UBYTE c __asm("d0"),APTR putChData __asm("a3"));
  extern VOID ParPutChar(UBYTE c __asm("d0"),APTR putChData __asm("a3"));
 
  /******************************************************************************/
 
  //STATIC PUTCHAR putChar = SerPutChar;
 
  /******************************************************************************/
 
  VOID
  ChooseParallelOutput(VOID)
  {
    Forbid();
 
    /* use the parallel port output routine. */
    kprintf("not support to use parallel output\n");
    //putChar = ParPutChar;
 
    Permit();
  }
 
  /******************************************************************************/
 
  VOID
  DVPrintf(const STRPTR format,const va_list varArgs)
  {
    /* printf() style text formatting and output */
    RawDoFmt((STRPTR)format,(APTR)varArgs,(void (*)())SerPutChar,NULL);
  }
"""

Thomas Richter
Germany

Posts 695
22 Mar 2010 14:12

bernd afa wrote:

>Have you considered the situation where a program releases memory >that does not have this cookie because it is releasing memory >that was allocated just *before* the patch was installed?
   
    this must handle by wipeout code(i dont know how it work), because when with installed wipeout a memblock was alloc before it have no cookie and wipeout cant add cookie size and free block as it can do when block is alloced with wipeout install.

I don't quite get what you're trying to say. Anyhow, I wouldn't play with programs I don't quite understand - then again, its of course your foot you shoot at...

bernd afa wrote:

    I try also static, but problem is the same.seem something GCC specific that not allow to put a function address in another pointer

Of course it does, this is standard ANSI C. You just need to declare the type correctly...

bernd afa wrote:

    typedef VOID (PUTCHAR)(UBYTE c __asm("d0"),APTR putChData __asm("a3"));

Think about this for a moment: What *does* this declare?

It declares a new type that is a function taking two arguments in registers. (Why do you write VOID instead of void? The function doesn't return anything, and unlike UBYTE, which may provide some compiler independence, VOID doesn't buy you anything) 
 
bernd afa wrote:
 
STATIC PUTCHAR putChar = SerPutChar;

Whereas *here*, you assign *a function* to another *function*. How is that supposed to work? Copy the subroutine over? (-:

You can assign an *address* of a function to a function *pointer*, and you can use pointers to functions interchangingly to functions itself:
 
STATIC PUTCHAR *putChar = &SerPutChar;

Now you can use the pointer(!) putChar as follows:

(*putChar)('c',array);

Because C is such a sloppy language, you can also write

putChar('c',array);

instead, noting that the pointer to the function is used *as if* it would be a function (though it isn't, it is a function pointer). 

Optionally, you may declare the PUTCHAR type as a function pointer in first place:

typedef void (*PUTCHAR)(UBYTE c __asm("d0"));

(what do you need a3 for, anyhow?)

As another side remark, you should check whether the mentioned functions really take the arguments as you expect. The RawIO serial output indeed takes the argument in d0 (but ignores a3, so why provide this as a parameter in first place?), but check the amiga.lib documentation whether the parallel version (which is not in exec) really takes the output character in d0. I'm not sure about this, it might be stack based (most calls in the amiga.lib are stack-based).

Greetings from Boston,

Thomas


Bernd Afa
Germany

Posts 146
22 Mar 2010 16:57

I find now the Bug in tlsfmem.
 
  it happen by this Code.
 
  muimaster.library +$10a6c
 
  MOVE.L  #$7FFFFFFF,D0  want alloc mem of 2 gb in size.
  MOVEQ  #0,D1         
  JSR    -$C6(A6)       
  LEA    $10F18B08(PC),A1
 
  seem this want flush all free mem, because it want alloc 2 gigabyte which no amiga system have.
 
  wipeout now add the cookie mem addon size to it and the memalloc is then do with 0x80000050.
 
  And the Bug in tlsfmem is that all sizes > 0x7fffffff return a illegal address (should return 0) and do enforcer hits because wipeout get the bad address from tlsfmem and want fill 0x7fffffff bytes with cookie.

I hope Chris fix that Bug.
 
  with muga have maybe same Problem.I think when tlsfmem is fix can here work too.only you need on start alloc the mem with.
 
  for (i = 0; i < maxallocs; i++)
      {
        if ((array.size = AvailMem(MEMF_LARGEST | MEMF_ANY)) == 0)
        {
        break;
        }
        if ((array.ptr = _allocany(array.size)) == NULL)
        {
        break;
        }
      }
 
  Thats the MOS code from itix and it work well with tlsfmem.
 
    >I don't quite get what you're trying to say. Anyhow, I wouldn't >play with programs I don't quite understand - then again, its of >course your foot you shoot at...
 
  i too dont want code on programs i not understand, but i need compile and look in debugger and singlestep how that work.
 
  Now i know how that work.this function do the Job.it detect if the mem is alloc with wipeout or its a old alloc
 
  IsValidTrackHeader(struct TrackHeader * th)
  {
    BOOL valid = FALSE;
 
    /* Check whether the calculated address looks good enough. */
    if(NOT IsInvalidAddress((ULONG)th) && NOT IsOddAddress((ULONG)th))
    {
    /* Check for the unique identifiers. */
    if(th->th_Magic == BASEBALL && th->th_PointBack == th)
      valid = TRUE;
    }
 
    return(valid);
  }
 
  every mem header contain this entries, so the size of the alloc is still in.
 
  but for new memhandlers the size can use and there need no support for partial free and check the memlist.
 
  this i add in wipeout so bad written programs that do partial free ,can detect and they can not silently damage the system.
 
  wipeout is also slow, i hope i can it speed up by avoid every memalloc a getsystime call.
 
    th->th_Magic  = BASEBALL;
    th->th_PointBack = th;
    th->th_PC  = pc;
    th->th_Owner  = FindTask(NULL);
    th->th_OwnerType = GetTaskType(NULL);
    th->th_NameTagLen = nameTagLen;
 
    GetSysTime(&th->th_Time);
    th->th_Sequence = Sequence++;
 
    th->th_Size  = memSize;
    th->th_PoolHeader = poolHeader;
    th->th_Type  = type;
    th->th_FillChar  = NewFillChar();
    th->th_PostSize  = postSize;
    th->th_Marked  = FALSE;
 
 
  >It declares a new type that is a function taking two arguments in >registers. (Why do you write VOID instead of void? The function >doesn't return anything, and unlike UBYTE,
 
  I don t know, the code i have not written, i only change the register par syntax to GCC.
 
  the functions should later link.this was asm code and i cant use in GCC
 
    xdef _SerPutChar
    xref KPutChar ; in debug.lib
 
  _SerPutChar:
    bra KPutChar
 
  *****************************************************************************
 
    xdef _ParPutChar
    xref PRawPutChar
 
  _ParPutChar:
    bra PRawPutChar ; in ddebug.lib
 
  *****************************************************************************
 
    end                   
 
  I have done the output to this function
  first i want call
 
  kprintf(STRPTR)format,(APTR)varArgs);
 
  but this dont work.so i do then this and it work
 
  char buff[32768];
  static const UWORD SerPutChar[] =
  {
  0x16C0, /* move.b d0,(a3)+ */
  0x4E75, /* rts */
  };
 
 
  VOID
  DVPrintf(const STRPTR format,const va_list varArgs)
  {
    /* printf() style text formatting and output */
    RawDoFmt((STRPTR)format,(APTR)varArgs,&SerPutChar,&buff[0]);
    kprintf("%s",&buff[0]);
  }
 

Thomas Richter
Germany

Posts 695
23 Mar 2010 07:07

bernd afa wrote:

I find now the Bug in tlsfmem.
   
    it happen by this Code.
 
  muimaster.library +$10a6c
   
    MOVE.L  #$7FFFFFFF,D0  want alloc mem of 2 gb in size.
    MOVEQ  #0,D1         
    JSR    -$C6(A6)       
    LEA    $10F18B08(PC),A1
   
  seem this want flush all free mem, because it want alloc 2 gigabyte which no amiga system have.

This code is fine, i.e. it should flush the code as you suspect.

bernd afa wrote:

    wipeout now add the cookie mem addon size to it and the memalloc is then do with 0x80000050.
   
    And the Bug in tlsfmem is that all sizes > 0x7fffffff return a illegal address (should return 0) and do enforcer hits because wipeout get the bad address from tlsfmem and want fill 0x7fffffff bytes with cookie.
 
  I hope Chris fix that Bug.

Keep him posted.
   
bernd afa wrote:

    with muga have maybe same Problem.

I do make bugs, but not this one. (-: Be ensured that I take care of this:


         move.l d2,d6                    ;keep me, too
         beq .nullsized
         cmp.l #$7fffff00,d2             ;flush only ?
         bhi .flushonly                  ;if so, just call the old AllocMem

with some additional code above and below to move registers around, check the stack size, etc... etc.... d2 is the total size of the memory to allocate, including footer and header.

Thus, thanks for reporting, but it's been taken care of.

bernd afa wrote:

    IsValidTrackHeader(struct TrackHeader * th)
    {
    BOOL valid = FALSE;
   
    /* Check whether the calculated address looks good enough. */
    if(NOT IsInvalidAddress((ULONG)th) && NOT IsOddAddress((ULONG)th))
    {
      /* Check for the unique identifiers. */
      if(th->th_Magic == BASEBALL && th->th_PointBack == th)
      valid = TRUE;
    }
   
    return(valid);
    }

Actually, memory addresses not only need to be even. They need to be divisble by eight.
 
bernd afa wrote:

    but for new memhandlers the size can use and there need no support for partial free and check the memlist.

I afraid not so. There is support for a partial free for the *regular* memory handler, as this technique is unfortunately in use, even by the Os up to v38. It is only *discouraged*, thus debugging tools should report it. Let it go and support it, but also report it. A debugging tool is not a regular program.

bernd afa wrote:

    wipeout is also slow, i hope i can it speed up by avoid every memalloc a getsystime call.

Bad choice. You can either make the system fast, or thorough. For a debugging tool, I have no need for a tool that is fast but *does not* report errors it could report. Why would I want to use it in first place?

Greetings, (from Snowbird)
Thomas


Bernd Afa
Germany

Posts 146
23 Mar 2010 10:08

>Actually, memory addresses not only need to be even. They need to >be divisble by eight.
 
  Yes thanks for info, this bring me in mind, that i need not do this lines
 
  if(NOT IsInvalidAddress((ULONG)th) && NOT IsOddAddress((ULONG)th))
 
  I think the check for cookie and the pointer to it is enough
 
  if(th->th_Magic == BASEBALL && th->th_PointBack == th)
 
  >Bad choice. You can either make the system fast, or thorough. For >a debugging tool, I have no need for a tool that is fast but >*does not* report errors it could report. Why would I want to use >it in first place?
 
  yes but wipeout is very slow, and it happen that when use wipeout on programs that use xml library or are written in C++(all do lots of small mem alloc/free) a program action can take easy over 2 minutes that normaly is done in 10 sec.
 
  Even on my fast winuae System.I get speedvalues from wipeout unter MOS here and tlsfmem, its more slow when run wipeout
 
  look here
 
  http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29569&forum=14&start=40&viewmode=flat&order=0#508818
 
  here are MOS values.need 21 sec for 1000 allocs
 
  http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29569&forum=14&start=80&viewmode=flat&order=0#509063
 
  its also usefull if you read more posts.
 
  maybe you have a idea wy wipeout is so slow ?
 
  I see it calc checksum over the header.
 
  getsystime i remove for test, it give no noticable speedup.so this is not a problem

  >I afraid not so. There is support for a partial free for the >*regular* memory handler, as this technique is unfortunately in >use, even by the Os up to v38. It is only *discouraged*, thus >debugging tools should report it.
 
  I do this test program
 
  a.l = AllocMem_(200,0)
  FreeMem_ a,100
  FreeMem_ a+100,100
 
  and i see that the first free give a message size diffrent to alloc in wipeout.but the second free give lots enforcer hits and read and write to illegal address from tlsfmem
 
  wipeout cant catch(by remove of the memlist tracking), because the cookie is not find and wipeout think its a old memalloc and call direct freemem
 
  So this must handle tlsfmem self.
 
  As far i remember partly free memory is in the SAS C resident program create startup.
  but its not a big problem, when the 2. partly free shoulfd do and when the address does not fit the alloc address, nothing is done.some few kb memloss is not important.it also happen selden.
 
  but tlsfmem should not do bad things.I dont understand btw wy its not possible by the allocator to free parts correct.I think also when a allocator have caches by size, its possible to remove a block and add it to other cache that fit the size of the free
 
  Enforcer Hit! Bad program
  Illegal LONG WRITE to: badedef7                PC: 1003c68e
  Data: badedeed 0000000e 00000018 d30329e9 18244aff 00000000 00000000 624c745a
  Addr: 1011eb48 293c6b28 1011f80c badedeef badedeef 1046a840 100008d4 116ba018
  Stck: 00000000 1118202c 00000000 1003c610 00030d40 00000000 00000000 00000000
  Stck: 11688e90 1003c18a 11888438 0000000c 00000004 00030d40 00000000 00000000
  Stck: 00000000 00000000 624c745a 10e60efe 118883d4 00000000 11688e90 00000000
  Stck: 00000000 100008d4 10e60efe 1188845e 118883da 10e4ad3a 00f9f86a 00031128
  Stck: 426c6974 7a205d5b 2050726f 6772616d 2050726f 63000000 00000000 00000000
  ----> 1003c68e - "tlsfmem" Hunk 0000 Offset 000008b6
  ----> 1003c610 - "tlsfmem" Hunk 0000 Offset 00000838
  ----> 1003c18a - "tlsfmem" Hunk 0000 Offset 000003b2
  ----> 10e60efe - "amiblitz2" Hunk 0000 Offset 0001a006
  ----> 10e60efe - "amiblitz2" Hunk 0000 Offset 0001a006
  ----> 10e4ad3a - "amiblitz2" Hunk 0000 Offset 00003e42
  ----> 10adf244 - "dopus5:modules/ftp.module" Hunk 0000 Offset 0000228c
  ----> 10adf244 - "dopus5:modules/ftp.module" Hunk 0000 Offset 0000228c
  1003c676 :  2180 242c            MOVE.L D0,(A0, D2.W*4, $2c) == $1011ebd4
  1003c67a :  6616                BNE.B #$00000016
  1003c67c :  2028 0028            MOVE.L (A0, $0028) == $1011eb70,D0
  1003c680 :  0580                BCLR.L D2,D0
  1003c682 :  2140 0028            MOVE.L D0,(A0, $0028) == $1011eb70
  1003c686 :  600a                BT .B #$0000000a
  1003c688 :  274c 0004            MOVE.L A4,(A3, $0004) == $badedef3
  1003c68c :  6704                BEQ.B #$00000004
  1003c68e : * 294b 0008            MOVE.L A3,(A4, $0008) == $badedef7
  1003c692 :  4cdf 1c01            MVMEL.L #$1c01,(A7)+
  1003c696 :  4e75                RTS.L
  1003c698 :  eb4a                LSL.W #$00000005,D2
  1003c69a :  48e7 0020            MVMLE.L #$0020,-(A7)
  1003c69e :  8441                OR.W D1,D2
  1003c6a0 :  42a9 0008            CLR.L (A1, $0008) == $293c6b30
  1003c6a4 :  45f0 2520 008c      LEA.L (A0, D2.W*4+140)+0 == $1011ec34,A2
  1003c6aa :  2352 0004            MOVE.L (A2),(A1, $0004) == $293c6b2c
  Name: "Blitz ][ Program Proc"
 
  Enforcer Hit! Bad program
  Illegal LONG WRITE to: badedef7                PC: 1003c68e
  Data: badedeed 0000000e 00000018 d30329e9 18244aff 00000000 00000000 624c745a
  Addr: 1011eb48 293c6b28 1011f80c badedeef badedeef 1046a840 100008d4 116ba018
  Stck: 00000000 1118202c 00000000 1003c610 00030d40 00000000 00000000 00000000
  Stck: 11688e90 1003c18a 11888438 0000000c 00000004 00030d40 00000000 00000000
  Stck: 00000000 00000000 624c745a 10e60efe 118883d4 00000000 11688e90 00000000
  Stck: 00000000 100008d4 10e60efe 1188845e 118883da 10e4ad3a 00f9f86a 00031128
  Stck: 426c6974 7a205d5b 2050726f 6772616d 2050726f 63000000 00000000 00000000
  ----> 1003c68e - "tlsfmem" Hunk 0000 Offset 000008b6
  ----> 1003c610 - "tlsfmem" Hunk 0000 Offset 00000838
  ----> 1003c18a - "tlsfmem" Hunk 0000 Offset 000003b2
  ----> 10e60efe - "amiblitz2" Hunk 0000 Offset 0001a006
  ----> 10e60efe - "amiblitz2" Hunk 0000 Offset 0001a006
  ----> 10e4ad3a - "amiblitz2" Hunk 0000 Offset 00003e42
  ----> 10adf244 - "dopus5:modules/ftp.module" Hunk 0000 Offset 0000228c
  ----> 10adf244 - "dopus5:modules/ftp.module" Hunk 0000 Offset 0000228c
  1003c676 :  2180 242c            MOVE.L D0,(A0, D2.W*4, $2c) == $1011ebd4
  1003c67a :  6616                BNE.B #$00000016
  1003c67c :  2028 0028            MOVE.L (A0, $0028) == $1011eb70,D0
  1003c680 :  0580                BCLR.L D2,D0
  1003c682 :  2140 0028            MOVE.L D0,(A0, $0028) == $1011eb70
  1003c686 :  600a                BT .B #$0000000a
  1003c688 :  274c 0004            MOVE.L A4,(A3, $0004) == $badedef3
  1003c68c :  6704                BEQ.B #$00000004
  1003c68e : * 294b 0008            MOVE.L A3,(A4, $0008) == $badedef7
  1003c692 :  4cdf 1c01            MVMEL.L #$1c01,(A7)+
  1003c696 :  4e75                RTS.L
  1003c698 :  eb4a                LSL.W #$00000005,D2
  1003c69a :  48e7 0020            MVMLE.L #$0020,-(A7)
  1003c69e :  8441                OR.W D1,D2
  1003c6a0 :  42a9 0008            CLR.L (A1, $0008) == $293c6b30
  1003c6a4 :  45f0 2520 008c      LEA.L (A0, D2.W*4+140)+0 == $1011ec34,A2
  1003c6aa :  2352 0004            MOVE.L (A2),(A1, $0004) == $293c6b2c
  Name: "Blitz ][ Program Proc"
 
  Enforcer Hit! Bad program
  Illegal LONG WRITE to: feabadce                PC: 1003c688
  Data: feabadc8 0000001f 00000018 d1aed7b1 18244aff 00000000 00000000 624c745a
  Addr: 1011eb48 18244aff 1011f850 feabadca feabadca 1046a840 100008d4 116ba018
  Stck: 00000000 1118202c 00000000 1003c630 00030d40 00000000 00000000 00000000
  Stck: 11688e90 1003c18a 11888438 0000000c 00000004 00030d40 00000000 00000000
  Stck: 00000000 00000000 624c745a 10e60efe 118883d4 00000000 11688e90 00000000
  Stck: 00000000 100008d4 10e60efe 1188845e 118883da 10e4ad3a 00f9f86a 00031128
  Stck: 426c6974 7a205d5b 2050726f 6772616d 2050726f 63000000 00000000 00000000
  ----> 1003c688 - "tlsfmem" Hunk 0000 Offset 000008b0
  ----> 1003c630 - "tlsfmem" Hunk 0000 Offset 00000858
  ----> 1003c18a - "tlsfmem" Hunk 0000 Offset 000003b2
  ----> 10e60efe - "amiblitz2" Hunk 0000 Offset 0001a006
  ----> 10e60efe - "amiblitz2" Hunk 0000 Offset 0001a006
  ----> 10e4ad3a - "amiblitz2" Hunk 0000 Offset 00003e42
  ----> 10adf244 - "dopus5:modules/ftp.module" Hunk 0000 Offset 0000228c
  ----> 10adf244 - "dopus5:modules/ftp.module" Hunk 0000 Offset 0000228c
  1003c670 :  2030 242c            MOVE.L (A0, D2.W*4, $2c) == $1011ebd4,D0
  1003c674 :  0380                BCLR.L D1,D0
  1003c676 :  2180 242c            MOVE.L D0,(A0, D2.W*4, $2c) == $1011ebd4
  1003c67a :  6616                BNE.B #$00000016
  1003c67c :  2028 0028            MOVE.L (A0, $0028) == $1011eb70,D0
  1003c680 :  0580                BCLR.L D2,D0
  1003c682 :  2140 0028            MOVE.L D0,(A0, $0028) == $1011eb70
  1003c686 :  600a                BT .B #$0000000a
  1003c688 : * 274c 0004            MOVE.L A4,(A3, $0004) == $feabadce
  1003c68c :  6704                BEQ.B #$00000004
  1003c68e :  294b 0008            MOVE.L A3,(A4, $0008) == $feabadd2
  1003c692 :  4cdf 1c01            MVMEL.L #$1c01,(A7)+
  1003c696 :  4e75                RTS.L
  1003c698 :  eb4a                LSL.W #$00000005,D2
  1003c69a :  48e7 0020            MVMLE.L #$0020,-(A7)
  1003c69e :  8441                OR.W D1,D2
  1003c6a0 :  42a9 0008            CLR.L (A1, $0008) == $18244b07
  Name: "Blitz ][ Program Proc"
 
 

Thomas Richter
Germany

Posts 695
23 Mar 2010 16:28

bernd afa wrote:

is very slow, and it happen that when use wipeout on programs that use xml library or are written in C++(all do lots of small mem alloc/free) a program action can take easy over 2 minutes that normaly is done in 10 sec.

And your point is? Don't run debugging tools unless you want to debug.
 
bernd afa wrote:

  >I afraid not so. There is support for a partial free for the >*regular* memory handler, as this technique is unfortunately in >use, even by the Os up to v38. It is only *discouraged*, thus >debugging tools should report it.
 
  I do this test program
 
  a.l = AllocMem_(200,0)
  FreeMem_ a,100
  FreeMem_ a+100,100
 
  and i see that the first free give a message size diffrent to alloc in wipeout.but the second free give lots enforcer hits and read and write to illegal address from tlsfmem

Ehem. According to my math, 100 is not divisible by eight, so *this* is definitely broken, even for a sloppy program. As icky as it may sound, but this nonsense is actually in use, even though it shouldn't.

bernd afa wrote:
 
  wipeout cant catch(by remove of the memlist tracking), because the cookie is not find and wipeout think its a old memalloc and call direct freemem
 
  So this must handle tlsfmem self.

In some sense. A debugging tool should *report* this problem, there is no need to actually handle it. But the regular memory manager should be able to keep care of it.

bernd afa wrote:
 
  As far i remember partly free memory is in the SAS C resident program create startup.

No, cres.o uses segment splitting or detaching the resident list from the CLI, which does not cause problems. This is fine. Layers v38 and below was a problem.

bernd afa wrote:
 
  Enforcer Hit! Bad program

"Enforcer" is now spelled "MuForce".

Greetings from Snowbird

Thomas


Wawa Tk
Germany

Posts 351
23 Mar 2010 17:47

Thomas Richter wrote:

bernd afa wrote:
 
    Enforcer Hit! Bad program
 

  "Enforcer" is now spelled "MuForce".


i believe this is the output from uaeenforcer. bernd doesnt work much on real hw for what i know.

Bernd Afa
Germany

Posts 146
23 Mar 2010 19:10

yes, i switch on my classic since years not.
The problem is that you can develop lots faster when you have fast Hardware.
 
  Time is short,
  you can not buy more time, but you can buy faster hardware or do better developing tools to save time.
 
  It help also a lot to find coding mistakes as soon as possible when you can always run on developing enforcer and wipeout.I do this always.
 
  and this should not slowdown the system.
 
  I think also every user should run this tools when he test new programs, so he can report problems soon.
 
  I see in ixemul it do always a 4 bytes front and rearwall check and there is no slowdown notice.
 
  So it should be really possible to get wipeout lots faster so there cant notice a slowdown with tlsfmem.
 
  because tlsfmem do memalloc faster, wipeout have more cycles left. 

Samuel D Crow
USA

Posts 544
24 Mar 2010 17:43

I thought that allocations had to be a multiple of 16 for compatibility with the BPTRs used in dos.library.  I think AGA depends on Chip memory allocations also being aligned that way also.

Thomas Richter
Germany

Posts 695
24 Mar 2010 18:19

Samuel D. Crow wrote:

I thought that allocations had to be a multiple of 16 for compatibility with the BPTRs used in dos.library.  I think AGA depends on Chip memory allocations also being aligned that way also.

BPTRs are shifted by two bits, that is, structures BPTRs point to need to be multiples of four (4 = 2^2).

Greetings,
Thomas


Bernd Afa
Germany

Posts 146
24 Mar 2010 19:25

>Ehem. According to my math, 100 is not divisible by eight, so >*this* is definitely broken, even for a sloppy program. As icky >as it may sound, but this nonsense is actually in use, even >though it shouldn't
 
  i test with that.
 
  a.l = AllocMem_(256,0)
  FreeMem_ a,128
  FreeMem_ a+128,128
 
  give too enforcer Hits

Thomas Richter
Germany

Posts 695
24 Mar 2010 20:20

bernd afa wrote:

    a.l = AllocMem_(256,0)
    FreeMem_ a,128
    FreeMem_ a+128,128
   
    give too enforcer Hits

"too" or "two"? (-;

Anyhow. This *should* work, thus whatever memory manager you're working with, it requires a fix. The exec internal one works fine. Forward to Chris for a fix.

As I said several times, as ugly as this may sound, it is a supported operation. This type of memory hack would allow a "realloc()" operation - i.e. dynamic resizing of a memory region. In your specific case, to shorten it. AllocAbs() is the counterpart, which allows you to - potentially - increase the size of an allocated array by allocating from the end of an already existing array. That should *also* work.

So long, and greetings from Snowbird,

Thomas


Bernd Afa
Germany

Posts 146
25 Mar 2010 17:50

>too" or "two"? (-;

too there come lots more than two enforcer Hits ;-)

I send a mail to Chris on 22. to his chrisly@ Mail address.

currently have no answer.I testet that with his latest tlsfmem 1.6 Version that was from 20.8.2008

if its not possible to handle that situation, there should at least the free ignore.

I have no programs that do free not the whole block, but a mem allocator should written, that there can not crash the system, if there really is such a program somewhere out.

I dont know if its possible to add in tlsfmem but at least a size value can add before every memory alloc and when the free size is diffrent to the size in the long then the free is ignore.this memm loss is acceptable because i dont think programs do that often to get lots memloss.

Bernd Afa
Germany

Posts 146
30 Mar 2010 18:59

I reassemble now tlsf and get it working in amiblitz i see it already contain a size value in each mem alloc.
 
  So i add code that it do nothing when there is a partly free called.wipeout work too and when this run can see that when a program free mem partly.
 
  also i see at the end of each alloc is a long data, and when a bad written program trash this value then a free do horrible things with AOS.
 
  So i like to add a long cookie value before and if that is wrong, then do nothing.
 
  then all is much more safe and we can be much more sure that there is no mem free on wrong address.
 
  that it help a lot to have a Parameter safe Memsystem, you can see on this Bug in texteditor class.
 
  AFA OS/AROS was the only AOS that do not total crash and the Mail was correct save.
 
  EXTERNAL LINK   
  this is reach by just check the parameters for Freemem if they are valid.
 
  but of course it costs 4 byte of additional memory each alloc in tlsf mem.
  thats in praxis not much more mem.when 1000 mem blocks are alloc its only 4000 bytes worst case.worst case i mean because tlsfmem use 16 byte align, so when there is a memalloc done with 4 upto 12 bytes the additional 4 bytes costs not more mem.because there can only alloc in steps 16 32 48 64.but over 16 bytes cost 16 bytes more.
 
  also i think overall with tlsfmem you have due to less fragmentation on low mem situation more mem available as with old mem handlers
 
  but i also like to know what other users think if i should release 2 versions, 1 risky but with 4 byte each alloc less mem usage and 1 more safe.
 
  What do others think ?
 
  new wipeout work too and is in a benchmark lots faster now.I add Mode quick.
 
  old wipeout do 13.000 k memallocs /sec new do over 100.000 k memallocs/sec.
 
  but strange is on amiblitz start, it give not much speedup.amiblitz start is still slow 7,5 sec with wipeout and under 1 sec without wipeout.
 
  I add also a semaphore amitlsf(i need rename tlsfmem Chris tell some time ago)
 
  this can use so programs as AFA or ixemul can check for the semaphore and if find, use tlsf allocator.

Thomas Richter
Germany

Posts 695
30 Mar 2010 20:26

Hi Bernd,

a couple of issues to watch out for:

*) If you add a cookie, you should also take care that the same cookie is set for AllocAbs(). This function is heavily required for memory allocations that are aligned to certain boundaries, For example, the MMU has certain alignment requirements, so has some hardware.

*) If you add a cookie, make sure that the pointer you return is a multiple of eight since software might depend on this.

*) You should note that a cookie itself is not a 100% problem-free approach as the very same pattern may also end up in memory by other means. Specifically, you should erase the cookie after having released the memory such that this "dead cookie" cannot be confused with one that is already active.

Greetings (from Newark this time),

Thomas



Dave DyLucke
Espania

Posts 62
31 Mar 2010 15:19

Erm, sorry about the intromission.

But, should i assume you're recompiling WIPEOUT in order to make it work on the Natami?

That would be awesome. For two reasons. If you are recompiling it that's because you have the engine source code.

If you have the source code, new maps, races and stuff could be added in the future. Right? That would be AWESOME. Since if Natami is able to run WIPEOUT, and i'm more than sure it will be able, some kind of port to use the original Wipeout 2097 or Wip3out file maps could be used. I guess.

Maybe i'm just daydreaming. XD

posts 30page  1 2