Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oneof's Message field builder does nothing when its sub-field changes #16

Closed
protobufel opened this issue Sep 8, 2014 · 2 comments
Closed
Labels

Comments

@protobufel
Copy link

Scenario:

  1. get field builder on oneof Message field
  2. set another field on this oneof
  3. mutate any field on the field builder (1)

Expected:

There are 2 alternatives:

  1. the exception like "this oneof field builder is unset" is raised, or
  2. the oneof and its case is set back to this field

Actual:

The field builder allows to mutate it with no warnings, and the oneof case is not changed back to this field!

Proposed Remedy:

Add extra oneofFieldChanged(Internal.EnumLite | FieldDescriptor) method to GeneratedMessage.BuilderParent interface, and notify parent of any oneof field builder's mutations.

When notified, either throw an exception if oneof is set to different case, or change the oneof's case to this field's case.

The good news is that it just clarifies the existing behavior and doesn't change any public interfaces and the existing techniques. Not implementing this fix will cause numerous, difficult to trace, logical problems with oneof in such a common scenario.

In addition, due to the wrong bundle number bug, you have to issue minor update anyway; so this would be the opportune time for the proposed solution.

Cheers,
David

PS: Here is the full JUnit 4 test case for the scenario as-is:

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.equalTo;
import static org.hamcrest.Matchers.is;

import org.junit.Test;

import protobuf_unittest.UnittestProto.TestAllTypes;
import protobuf_unittest.UnittestProto.TestAllTypes.Builder;
import protobuf_unittest.UnittestProto.TestAllTypes.OneofFieldCase;

public class OneofPropertyChangeTest {

@test
public void testOneOfPropertyChangeGeneratedBuilder() {
final Builder builder = TestAllTypes.newBuilder().setOneofString("hello");
assertThat(builder.getOneofFieldCase(), is(equalTo(OneofFieldCase.ONEOF_STRING)));

final TestAllTypes.NestedMessage.Builder innerBuilder = builder.getOneofNestedMessageBuilder();
assertThat(builder.getOneofFieldCase(), is(equalTo(OneofFieldCase.ONEOF_NESTED_MESSAGE)));

builder.setOneofString("hello again");
assertThat(builder.getOneofFieldCase(), is(equalTo(OneofFieldCase.ONEOF_STRING)));

/** 
 * when oneof's field builder property changes, either set oneof to this 
 * field, or raise exception when other field set on this oneof already!
 * At present, the builder will allow any its mutation with no effect on its parent!   
 */
innerBuilder.setBb(999);
// the following should not be failing, but it fails!
assertThat(builder.getOneofFieldCase(), is(equalTo(OneofFieldCase.ONEOF_NESTED_MESSAGE)));

}
}

@xfxyjwf
Copy link
Contributor

xfxyjwf commented Sep 8, 2014

We had a discussion about field lifetime issue just recently and here is assumption that I think users should make when accessing sub-fields of a protobuf message:

After getting a reference/pointer to a field of a protobuf message, any subsequent mutation method calls to the message may invalidate this reference/pointer and accessing this reference/pointer is an undefined behavior.

This not only applies to the case you mentioned, but also applies to other cases and other languages. For example, step 3 in the following scenario will result in undefined behavior:

  1. List<Integer> list = builder.getRepeatedFieldList();
  2. builder.addRepeatedField(value);
  3. for (Integer element : list) {...}

It might be better to throw an exception to let the user aware of the problem, but given the implementation overhead to address this, I would prefer leaving it as-is.

@xfxyjwf xfxyjwf added the wontfix label Sep 8, 2014
@protobufel
Copy link
Author

Collections' modCount like? :)

Understood!

David

@xfxyjwf xfxyjwf closed this as completed Sep 10, 2014
TeBoring pushed a commit to TeBoring/protobuf that referenced this issue Jan 19, 2019
Resolve compilation errors if compiled with strict warnings.
copybara-service bot pushed a commit that referenced this issue Oct 10, 2024
…um value is detected.

This should never happen, so I don't think it matters much exactly what kind of
exception we throw. We could even arguably return null, but this option saves a
lot of space while still preserving some error checking.

See https://godbolt.org/z/jKhcKs3x1 for code gen.

This generates much tighter bytecode and ARM assembly than alternatives.

As this code is generated many times over, small wins in code size here can
reduce icache pressure, APK size, and OAT size.

This java code:

```java
  Object uoe() {
       throw new UnsupportedOperationException();
  }
  Object npe2() {
    throw null;
  }
```

Generates this dex code:

```
.method uoe()Ljava/lang/Object;
    new-instance v0, Ljava/lang/UnsupportedOperationException;
    invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V
    throw v0
.end method

.method npe2()Ljava/lang/Object;
    const/4 v0, 0x0
    throw v0
.end method
```

Which generates this OAT code:

```
java.lang.Object SomeProto.uoe() [84 bytes]
    0x000081c0    sub x16, sp, #0x2000 (8192)
    0x000081c4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000081c8    str x0, [sp, #-48]!
    0x000081cc    str x22, [sp, #24]
    0x000081d0    stp x23, lr, [sp, #32]
    0x000081d4    ldr x21, [x21]
     StackMap[1]   native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000081d8    mov x22, x1
    0x000081dc    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081e0    ldr w0, [x0, #4]
    0x000081e4    ldr lr, [tr, #464] ; pAllocObjectInitialized
    0x000081e8    blr lr
     StackMap[2]   native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b
    0x000081ec    dmb ishst
    0x000081f0    mov x1, x0
    0x000081f4    mov x23, x1
    0x000081f8    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081fc    ldr w0, [x0, #12]
    0x00008200    ldr lr, [x0, #24]
    0x00008204    blr lr
     StackMap[3]   native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b
    0x00008208    mov x0, x23
    0x0000820c    ldr lr, [tr, #1264] ; pDeliverException
    0x00008210    blr lr
     StackMap[4]   native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b

java.lang.Object SomeProto.npe2() [36 bytes]
    0x000080d0    sub x16, sp, #0x2000 (8192)
    0x000080d4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000080d8    str x0, [sp, #-32]!
    0x000080dc    stp x22, lr, [sp, #16]
    0x000080e0    ldr x21, [x21]
     StackMap[1]   native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000080e4    mov x22, x1
    0x000080e8    mov w0, #0x0
    0x000080ec    ldr lr, [tr, #1264] ; pDeliverException
    0x000080f0    blr lr
     StackMap[2]   native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b
```

This saves 84-36 = 48 bytes of OAT per method.

PiperOrigin-RevId: 684258075
copybara-service bot pushed a commit that referenced this issue Oct 10, 2024
…um value is detected.

This should never happen, so I don't think it matters much exactly what kind of
exception we throw. We could even arguably return null, but this option saves a
lot of space while still preserving some error checking.

See https://godbolt.org/z/jKhcKs3x1 for code gen.

This generates much tighter bytecode and ARM assembly than alternatives.

As this code is generated many times over, small wins in code size here can
reduce icache pressure, APK size, and OAT size.

This java code:

```java
  Object uoe() {
       throw new UnsupportedOperationException();
  }
  Object npe2() {
    throw null;
  }
```

Generates this dex code:

```
.method uoe()Ljava/lang/Object;
    new-instance v0, Ljava/lang/UnsupportedOperationException;
    invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V
    throw v0
.end method

.method npe2()Ljava/lang/Object;
    const/4 v0, 0x0
    throw v0
.end method
```

Which generates this OAT code:

```
java.lang.Object SomeProto.uoe() [84 bytes]
    0x000081c0    sub x16, sp, #0x2000 (8192)
    0x000081c4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000081c8    str x0, [sp, #-48]!
    0x000081cc    str x22, [sp, #24]
    0x000081d0    stp x23, lr, [sp, #32]
    0x000081d4    ldr x21, [x21]
     StackMap[1]   native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000081d8    mov x22, x1
    0x000081dc    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081e0    ldr w0, [x0, #4]
    0x000081e4    ldr lr, [tr, #464] ; pAllocObjectInitialized
    0x000081e8    blr lr
     StackMap[2]   native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b
    0x000081ec    dmb ishst
    0x000081f0    mov x1, x0
    0x000081f4    mov x23, x1
    0x000081f8    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081fc    ldr w0, [x0, #12]
    0x00008200    ldr lr, [x0, #24]
    0x00008204    blr lr
     StackMap[3]   native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b
    0x00008208    mov x0, x23
    0x0000820c    ldr lr, [tr, #1264] ; pDeliverException
    0x00008210    blr lr
     StackMap[4]   native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b

java.lang.Object SomeProto.npe2() [36 bytes]
    0x000080d0    sub x16, sp, #0x2000 (8192)
    0x000080d4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000080d8    str x0, [sp, #-32]!
    0x000080dc    stp x22, lr, [sp, #16]
    0x000080e0    ldr x21, [x21]
     StackMap[1]   native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000080e4    mov x22, x1
    0x000080e8    mov w0, #0x0
    0x000080ec    ldr lr, [tr, #1264] ; pDeliverException
    0x000080f0    blr lr
     StackMap[2]   native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b
```

This saves 84-36 = 48 bytes of OAT per method.

PiperOrigin-RevId: 684258075
copybara-service bot pushed a commit that referenced this issue Oct 10, 2024
…um value is detected.

This should never happen, so I don't think it matters much exactly what kind of
exception we throw. We could even arguably return null, but this option saves a
lot of space while still preserving some error checking.

See https://godbolt.org/z/jKhcKs3x1 for code gen.

This generates much tighter bytecode and ARM assembly than alternatives.

As this code is generated many times over, small wins in code size here can
reduce icache pressure, APK size, and OAT size.

This java code:

```java
  Object uoe() {
       throw new UnsupportedOperationException();
  }
  Object npe2() {
    throw null;
  }
```

Generates this dex code:

```
.method uoe()Ljava/lang/Object;
    new-instance v0, Ljava/lang/UnsupportedOperationException;
    invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V
    throw v0
.end method

.method npe2()Ljava/lang/Object;
    const/4 v0, 0x0
    throw v0
.end method
```

Which generates this OAT code:

```
java.lang.Object SomeProto.uoe() [84 bytes]
    0x000081c0    sub x16, sp, #0x2000 (8192)
    0x000081c4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000081c8    str x0, [sp, #-48]!
    0x000081cc    str x22, [sp, #24]
    0x000081d0    stp x23, lr, [sp, #32]
    0x000081d4    ldr x21, [x21]
     StackMap[1]   native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000081d8    mov x22, x1
    0x000081dc    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081e0    ldr w0, [x0, #4]
    0x000081e4    ldr lr, [tr, #464] ; pAllocObjectInitialized
    0x000081e8    blr lr
     StackMap[2]   native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b
    0x000081ec    dmb ishst
    0x000081f0    mov x1, x0
    0x000081f4    mov x23, x1
    0x000081f8    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081fc    ldr w0, [x0, #12]
    0x00008200    ldr lr, [x0, #24]
    0x00008204    blr lr
     StackMap[3]   native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b
    0x00008208    mov x0, x23
    0x0000820c    ldr lr, [tr, #1264] ; pDeliverException
    0x00008210    blr lr
     StackMap[4]   native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b

java.lang.Object SomeProto.npe2() [36 bytes]
    0x000080d0    sub x16, sp, #0x2000 (8192)
    0x000080d4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000080d8    str x0, [sp, #-32]!
    0x000080dc    stp x22, lr, [sp, #16]
    0x000080e0    ldr x21, [x21]
     StackMap[1]   native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000080e4    mov x22, x1
    0x000080e8    mov w0, #0x0
    0x000080ec    ldr lr, [tr, #1264] ; pDeliverException
    0x000080f0    blr lr
     StackMap[2]   native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b
```

This saves 84-36 = 48 bytes of OAT per method.

PiperOrigin-RevId: 684258075
copybara-service bot pushed a commit that referenced this issue Oct 10, 2024
…um value is detected.

This should never happen, so I don't think it matters much exactly what kind of
exception we throw. We could even arguably return null, but this option saves a
lot of space while still preserving some error checking.

See https://godbolt.org/z/jKhcKs3x1 for code gen.

This generates much tighter bytecode and ARM assembly than alternatives.

As this code is generated many times over, small wins in code size here can
reduce icache pressure, APK size, and OAT size.

This java code:

```java
  Object uoe() {
       throw new UnsupportedOperationException();
  }
  Object npe2() {
    throw null;
  }
```

Generates this dex code:

```
.method uoe()Ljava/lang/Object;
    new-instance v0, Ljava/lang/UnsupportedOperationException;
    invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V
    throw v0
.end method

.method npe2()Ljava/lang/Object;
    const/4 v0, 0x0
    throw v0
.end method
```

Which generates this OAT code:

```
java.lang.Object SomeProto.uoe() [84 bytes]
    0x000081c0    sub x16, sp, #0x2000 (8192)
    0x000081c4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000081c8    str x0, [sp, #-48]!
    0x000081cc    str x22, [sp, #24]
    0x000081d0    stp x23, lr, [sp, #32]
    0x000081d4    ldr x21, [x21]
     StackMap[1]   native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000081d8    mov x22, x1
    0x000081dc    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081e0    ldr w0, [x0, #4]
    0x000081e4    ldr lr, [tr, #464] ; pAllocObjectInitialized
    0x000081e8    blr lr
     StackMap[2]   native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b
    0x000081ec    dmb ishst
    0x000081f0    mov x1, x0
    0x000081f4    mov x23, x1
    0x000081f8    adrp x0, #+0x4000 (addr 0x0000c000)
    0x000081fc    ldr w0, [x0, #12]
    0x00008200    ldr lr, [x0, #24]
    0x00008204    blr lr
     StackMap[3]   native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b
    0x00008208    mov x0, x23
    0x0000820c    ldr lr, [tr, #1264] ; pDeliverException
    0x00008210    blr lr
     StackMap[4]   native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b

java.lang.Object SomeProto.npe2() [36 bytes]
    0x000080d0    sub x16, sp, #0x2000 (8192)
    0x000080d4    ldr wzr, [x16]
     StackMap[0]   native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b
    0x000080d8    str x0, [sp, #-32]!
    0x000080dc    stp x22, lr, [sp, #16]
    0x000080e0    ldr x21, [x21]
     StackMap[1]   native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b
    0x000080e4    mov x22, x1
    0x000080e8    mov w0, #0x0
    0x000080ec    ldr lr, [tr, #1264] ; pDeliverException
    0x000080f0    blr lr
     StackMap[2]   native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b
```

This saves 84-36 = 48 bytes of OAT per method.

PiperOrigin-RevId: 684620833
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants