Subject: RE: [rohc] SigComp torture tests

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 14 Mar 2005 09:35:02 -0000

Hi Pekka, 

I've run this torture test plus the other 2 you suggested for
torture-tests-00.txt with the following results:

Use 3485 state:
	Agrees with the stated output and number of cycles :-)

Bytecode state creation:

	Message 2 does not work - the bytes given under 'Second message' are
not the same as the ones given in the textual description higher up.  The
message in the textual description is the one that references state
correctly.  I don't think there is any need for the messages to be given
twice and there is a good description of what the messages do before the
bytecode so I've suggested some alternative text below.

	The output from the 2nd message I get is 0x4f4b 32 (rather than 31
at the end).  Is this correct (as far as I can see from the mnemonic code,
it should be 32)?  (This means I agree with Herve.)

	Again for message 3, the last byte of output I get is 32 rather than
31.  (And again, I agree with Herve.)

	The number of cycles are the same as stated.

	General comments:

		Having worked out what this bytecode does, I think the
description is slightly misleading - the bytecode isn't self-modifying as
the area containing bytecode is never overwritten during its execution.  I
suggest removal of the words "self-modifying byte code," from the
description.

		One addition to the test is that of switching the LOAD and
first STATE-CREATE instructions.  This would then also check that if the
area to be saved is modified after the STATE-CREATE request, it still works.
What do you think?

	Updated text for this test is given below.

Updated state creation text:

> 
> That is the corner case 4 in 2.15. However it looks like the code
> does not actually test corner case 3, "An item of state is created
> and then freed by the same message."

I partly agree and partly disagree with you.  When the test message is 0x06
a piece of state is created (but already exists) and then freed thus
carrying out the test, unless we want to be very picky (which I have no
objection to being) about when the state is first created.  When the test
message is 0x07 the piece of state is created, freed and then created again
- again coming to within an inch of what the test says but without any way
to completely verify it because the state is re-created.  

In this respect, I think the test is ok as it is, but if in changing it (see
below) we can make the test really complete, then I'm quite happy to do it.

> 
> Perhaps the test should input partial_identifier_length, too. The
> code below is designed to test yet another corner case, if the
> STATE-FREE partial_identifier_length does not lie between 6 and 20
> inclusive then decompression failure should occur.
> 
Yes I agree.  This is a good point.

I am quite happy with the bytecode and will put it in the next version of
the draft.

I have some comments on the expected results:

> I expect following results:
> 
>    Compressed message:     State item in compartment:     UDVM cycles:
>         0x0606                        Yes                      23
I ended up with no state in the compartment because it is created and then
freed (using 6 bytes of identifier which is ok) as in the original test.

>         0x0614                        No                       23 

This test is essentially the same as 0x0606 but does begin with no state, so
it does COMPLETELY fulfil corner case 3 - the state is created and then
freed, so I'm happy to leave it in.

>         0x0706                        Yes                      33

>         0x0714                        Yes                      33
These two tests are identical because it is possible to free the state with
both 6 and 20 bytes of identifier.  They both create, free and then
re-create the state.  I'm not sure there is particularly any need for this
test, but if we keep it, then we only need it once.

I'll update the text for this test when we have concluded which of the above
should be in it.

All thoughts appreciated.  Updated text for section 4.5 included below.

Best regards,

Abbie

"4.5  Bytecode state creation

   This section gives assembly code to test storing bytecode using
   END-MESSAGE and later loading the bytecode using a partial state
   identifier within the SigComp header.  The assembly code is designed
   so that it includes testing changing bytes to be stored after the
   state create request, loading byte code in special memory areas and
   correct initialization order of the UDVM.
   1.  Three items of bytecode state are created.  The bytes to be saved
       change after the first state create request.
   2.  The bytecode is loaded using partial state identifier.
   3.  The bytecode is loaded using partial state identifier.  Part of
       the loaded memory is reserved area, which is overwritten after
       loading the bytecode.
   4.  The byte loading fails because partial state identifier is too
       short.

   at (30)

   :save_area1
   set (saved_instr1, (save_area1 + (code_start2 - start_saved)))

   at (80)

   :save_area2
   set (saved_instr2, (save_area2 + (code_start2 - start_saved)))

   at (128)

   :code_start
   COPY (start_saved, saved_len, save_area1)
   STATE-CREATE (saved_len, save_area1, saved_instr1, 6, 10)

   set (modify1, (save_area1 + 5))
   LOAD (modify1, 0x1e03)

   COPY (start_saved, saved_len, save_area2)
   STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10)

   OUTPUT (ok1, 3)

   END-MESSAGE (0, 0, saved_len, save_area2, saved_instr2, 12, 10)

   :ok1
   byte (0x4f, 0x4b, 0x31)

   set (saved_len, (end_saved - start_saved))

   :start_saved
   byte (0x4f, 0x4b, 0x32)

   :code_start2

   ; OUTPUT (save_area2, 3)
   byte (0x22, 0xa0, 0x50, 0x03)

   ; END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
   byte (0x23)

   :end_saved

   The expected outputs and cycle usages are:

   Message              Output                  Cycles
   1                    0x4f4b 31               50
   2                    0x4f4b 32               5
   3                    0x0000 32               5
   4                    None                    Decompression failure

   First message:

   0xf803 6112 a0ae 081e 2008 1e21 060a 0e23 be03 12a0 ae08 a050 2008
   0xa050 a053 140a 22a0 ab03 2300 0008 a050 a053 0c0a 4f4b 314f 4b32
   0x22a0 5003 23

   Second message:

   0xfb24 63cd ff5c f8c7 6df6 a289 ff

   Third message:

   0xf95b 4b43 d567 83

   Fourth message:

   0xf9de 8126 1199 1f"

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 14 Mar 2005 19:21:49 +0200

Hi Abigail,

>it should be 32)?  (This means I agree with Herve.)

A copy and paste error, I'm sorry. My own test driver uses 4f 4b 32, too.

>suggest removal of the words "self-modifying byte code," from the

You are absolute right. I wrote the test case because some UDVM
implementations had problems with my bytecode, one when the
bytecode was modified, another when the bytecode state started
before 128. The contributed torture test case does not test
self-modification, only the second problematic case. 

Now I added a INPUT-BYTES modifying the OUTPUT() instruction,
please see the modified UDVM assembly and messages below.

>area to be saved is modified after the STATE-CREATE request, it still works.

That sounds great. 

>	Updated text for this test is given below.

Again...

--Pekka

4.5  Bytecode state creation

   This section gives assembly code to test storing bytecode using
   END-MESSAGE and later loading the bytecode using a partial state
   identifier within the SigComp header.  The assembly code is designed
   so that it includes testing changing bytes to be stored after the
   state create request, loading byte code in special memory areas and
   correct initialization order of the UDVM.
   1.  Four items of bytecode state are created.  The bytes to be saved
       change after the first state create request.  The uploaded bytecode
       is modified before execution.
   2.  The bytecode is loaded using partial state identifier and modified.
   3.  The bytecode is loaded before 128 using partial state identifier.
   4.  The bytecode is loaded using partial state identifier.  Part of
       the loaded memory is reserved area, which is overwritten after
       loading the bytecode.
   5.  The byte loading fails because partial state identifier is too
       short.

	at (30)
:save_area1

	at (80)
:save_area2

	at (128)
:code_start

	COPY (start_saved, saved_len, save_area2)
	STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10)
	STATE-CREATE (saved_len, save_area2, saved_instr2, 12, 10)
	JUMP (modify)

:ok1	byte (0x4f, 0x4b, 0x31)

:modify
	INPUT-BYTES (1, (after_output - 1), !)
	OUTPUT (ok1, 3)
:after_output

	; Save from ok1 to the opcode of END-MESSAGE 
	set (modify_len, ((after_output + 1) - ok1))

	END-MESSAGE (0, 0, modify_len, ok1, modify, 6, 10)

:start_saved
	byte (0x4f, 0x4b, 0x32)
:code_start2
	; OUTPUT (save_area2, 3)

   Message              Output                  Cycles
   1                    0x4f4b                  67
   1                    0x4f4b 31               7
   2                    0x4f4b 32               5
   3                    0x0000 32               5

   First message:

   0xf804 6112 a0be 081e 2008 1e21 060a 0e23 be03 12a0 be08 a050 2008
   0xa050 a053 140a 2008 a050 a053 0c0a 1605 4f4b 311c 01a0 b39f 5522
   0xa0a7 0323 0000 0ea0 a7a0 aa06 0a4f 4b32 22a0 5003 2302

   Second message:

   0xf953 e97f 4afd d203

   Third message:

   Fourth message:

   0xf95b 4b43 d567 83

   Fifth message:
   
   0xf9de 8126 1199 1f"

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 14 Mar 2005 19:54:04 +0200

Hi Abigain,

>Updated state creation text:

...

>below) we can make the test really complete, then I'm quite happy to do it.

The original test was perfect, however, I thought that I had found
a yet another bug in my UDVM implementation. Indeed, STATE-FREE
can free a state using shorter id than the minimum *access*
length, however, my debugging output routine tried to access the
state leading to confused printout. Not to speak about tester.

If you like to add some more corner cases to
STATE-CREATE/STATE-FREE, here is a yet another bytecode doing
that:

0xf809 411c 01a0 459f 7f04 220b 1762 8f0d 0606 200a a10a 0014 0004
0x2201 1762 8f0c 0606 200a 8800 1400 0422 0117 628f 1606 061c 01a0
0x479f 5121 a048 6312 a0e4 63a0 4804 2201 1762 8f0a 0606 21a0 e406
0x0422 0117 628f 0e06 0623 0000 0a88 0014 0023 0000 0000 0000 0043
0x7ae8 0a0f dc1e 6a87 c1b6 2a76 76b9 7331 8c0e f500 0000 0000 0000
0x00c0 cc3f ee79 bcfc 8fd1 0865 e803 52ee 2977 17df 57  

The extra corner cases are as follows:

   5.  The STATE-FREE instruction has partial_identifer_length
   operand shorter than 6 or longer than 20.

   6.  The STATE-FREE instruction specifies a partial_identifier that
   matches with two state items in the compartment.

And the test messages:

   Compressed message:       Number of state items:     UDVM cycles:
        0x00                          0                      13
        0x01                          1                      23
        0x02                          0                      14
        0x03                          1                      24

        0x0400                        Decompression failure                      
        0x0420                        Decompression failure                      
        0x0406                        No                     23

        0x09                          1                      34
        0x0a                          0                      25
        0x0b                          1                      35

        0x1a                          2                      36
        0x1e06                        2                      46
        0x1e07                        0                      47
        0x1e14                        0                      60
        0x1f14                        1                      70

I took the UDVM cycle count from my notoriously reliable
debugging output. Caveat emptor.

--Pekka

at (64)

:byte_copy_left                 pad (2)
:byte_copy_right                pad (2)
:states                         pad (1)
:states_lsb                     pad (1)
:min_len                        pad (1)
:min_len_lsb                    pad (1)

:state_identifier		pad (20)

set (state_length, 10)

at (128)

	INPUT-BYTES (1, states_lsb, !)

:test_one
	LSHIFT ($states, 11)
	COMPARE ($states, 32768, test_two, create_state_a2, create_state_a2)
:create_state_a2
	STATE-CREATE (state_length, state_address2, 0, 20, 0)

:test_two
	LSHIFT ($states, 1)
	COMPARE ($states, 32768, test_three, create_state_a, create_state_a)
:create_state_a
	STATE-CREATE (state_length, state_address, 0, 20, 0)

:test_three
	LSHIFT ($states, 1)
	COMPARE ($states, 32768, test_four, free_state, free_state)
:free_state
	INPUT-BYTES (1, min_len_lsb, !)
	STATE-FREE (state_identifier, $min_len)
	COPY (identifier1, $min_len, state_identifier)

:test_four
	LSHIFT ($states, 1)
	COMPARE ($states, 32768, test_five, free_state2, free_state2)
:free_state2
	STATE-FREE (identifier1, 6)

:test_five
	LSHIFT ($states, 1)
	COMPARE ($states, 32768, end, create_state_b, create_state_b)
:create_state_b
	END-MESSAGE (0, 0, state_length, state_address, 0, 20, 0)
:end
	END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

:identifier1
	byte (67, 122, 232, 10, 15, 220, 30, 106, 135, 193, 182, 42, 118, 118, 185, 115, 49, 140, 14, 245)

	at (256)
:state_address
	byte (192, 204, 63, 238, 121, 188, 252, 143, 209, 8)
:state_address2
	byte (101, 232, 3, 82, 238, 41, 119, 23, 223, 87)