touch-packages team mailing list archive

[Daniel van Vugt <daniel.van.vugt@xxxxxxxxxxxxx>]

mir (0.13.3+15.10.20150617-0ubuntu1) wily; urgency=medium

  [ Alberto Aguirre ]
  * New upstream release 0.13.3 (https://launchpad.net/mir/+milestone/0.13.3)
    - Bug fixes:
      . mir-client-platform-mesa-dev package dep is incorrect (LP: #1465642)
      . Avoid allocating mir protobuf message objects on stack (LP: #1465883)

 -- CI Train Bot <ci-train-bot@xxxxxxxxxxxxx>  Wed, 17 Jun 2015 20:02:15
+0000

** Changed in: mir/0.13
       Status: Triaged => Fix Released

** Changed in: mir/0.13
     Assignee: (unassigned) => Alberto Aguirre (albaguirre)

** Also affects: mir (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: mir (Ubuntu)
       Status: New => Fix Released

** Changed in: mir (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mir in Ubuntu.
https://bugs.launchpad.net/bugs/1465883

Title:
  libmirprotobuf's ABI can be broken when modifying protobuf message
  definitions

Status in Mir:
  Fix Committed
Status in Mir 0.13 series:
  Fix Released
Status in mir package in Ubuntu:
  Fix Released

Bug description:
  libmirprotobuf's ABI can be broken when modifying protobuf message
  definitions.

  This is normally not an issue because updates keep replacing
  libmirclient.so.8 unless we bump client ABI.

  Existing clients linked to libmirclient8 (like glmark2) will use the
  old message layouts, however when linked to newer versions of
  libmirprotobuf.so.0 at runtime those messages can be bigger or
  potentially  different. Allocating these messages on the stack in
  libmirclient means this causes stack corruption and crashes.

  Ideally, we should bump libmirprotobuf ABI but that's not currently possible since:
  - protobuf design does not allow symbols to be registered twice
  - libmirprotobuf does not version its symbols
  - consequently a libmirprotobuf.so.0 and libmirprotobuf.so.1 cannot be loaded in the same process at the same time
  - Loading two libmirprotobuf library versions at the same time would be common since the mesa client platform module is linked against libmirclient - just probing the module would cause a new version of libmirprotobuf to load

  The mir team most commonly just adds additional fields to a protobuf
  message. To improve compatibility in this case, we can avoid
  allocating protobuf messages on the stack and instead use the factory
  methods provided by the generated message classes which are defined in
  libmirprotobuf itself.

  We still need to tread carefully when modifying protobuf message
  definitions however, to avoid changing class layouts in a non-
  compatible way (like removing fields or adding fields in the midle of
  existing ones)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mir/+bug/1465883/+subscriptions