| 2015-06-16 23:34:43 |
Alberto Aguirre |
bug |
|
|
added bug |
| 2015-06-16 23:34:59 |
Alberto Aguirre |
nominated for series |
|
mir/0.13 |
|
| 2015-06-16 23:34:59 |
Alberto Aguirre |
bug task added |
|
mir/0.13 |
|
| 2015-06-16 23:35:04 |
Alberto Aguirre |
mir/0.13: milestone |
|
0.13.3 |
|
| 2015-06-16 23:35:07 |
Alberto Aguirre |
mir: milestone |
|
0.14.0 |
|
| 2015-06-16 23:37:28 |
Launchpad Janitor |
branch linked |
|
lp:~albaguirre/mir/fix-1465883 |
|
| 2015-06-17 04:51:54 |
Daniel van Vugt |
summary |
avoid allocating mir protobuf message objects on the stack |
MIRPROTOBUF_ABI is being broken by message design changes, but MIRPROTOBUF_ABI is never bumped resulting in client crashes. |
|
| 2015-06-17 04:52:43 |
Daniel van Vugt |
summary |
MIRPROTOBUF_ABI is being broken by message design changes, but MIRPROTOBUF_ABI is never bumped resulting in client crashes. |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes. |
|
| 2015-06-17 04:52:52 |
Daniel van Vugt |
description |
Avoid allocating mir protobuf message objects on the stack to improve compatibility when an older libmirclient library uses a newer updated libmirprotobuf library. |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes. |
|
| 2015-06-17 04:53:38 |
Daniel van Vugt |
mir: importance |
Medium |
High |
|
| 2015-06-17 04:53:42 |
Daniel van Vugt |
mir/0.13: importance |
Undecided |
High |
|
| 2015-06-17 04:53:45 |
Daniel van Vugt |
mir/0.13: status |
New |
Triaged |
|
| 2015-06-17 04:56:38 |
Daniel van Vugt |
description |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes. |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes.
Existing clients linked to libmirclient8 (like glmark2) are therefore using the old message layouts, however linked to newer versions of libmirprotobuf.so.0 at runtime where those messages are now bigger and different. Allocating these messages on the stack in libmirclient means this causes stack corruption and crashes.
Essentially we've just been breaking the ABI while failing to protect clients by bumping the ABI number. |
|
| 2015-06-17 04:58:39 |
Daniel van Vugt |
description |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes.
Existing clients linked to libmirclient8 (like glmark2) are therefore using the old message layouts, however linked to newer versions of libmirprotobuf.so.0 at runtime where those messages are now bigger and different. Allocating these messages on the stack in libmirclient means this causes stack corruption and crashes.
Essentially we've just been breaking the ABI while failing to protect clients by bumping the ABI number. |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes.
Existing clients linked to libmirclient8 (like glmark2) are therefore using the old message layouts, however linked to newer versions of libmirprotobuf.so.0 at runtime where those messages are now bigger and different. Allocating these messages on the stack in libmirclient means this causes stack corruption and crashes.
Essentially we've just been breaking the ABI while failing to protect clients by bumping the ABI number.
The problem only becomes visible however when a client is given a newer libmirprotobuf.so.0 while it keeps its older libmirclient.so.8. Such as when be bumped the client ABI recently. |
|
| 2015-06-17 06:44:45 |
Daniel van Vugt |
branch linked |
|
lp:~mir-team/mir/fix-1465883-and-1341490 |
|
| 2015-06-17 06:48:14 |
Daniel van Vugt |
summary |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes. |
libmirprotobuf's ABI has been broken by message design changes, resulting in client crashes and/or leaks |
|
| 2015-06-17 15:44:29 |
Alberto Aguirre |
summary |
libmirprotobuf's ABI has been broken by message design changes, resulting in client crashes and/or leaks |
avoid allocating mir protobuf message objects on the stack |
|
| 2015-06-17 15:49:16 |
Alberto Aguirre |
summary |
avoid allocating mir protobuf message objects on the stack |
Avoid allocating mir protobuf message objects on the stack |
|
| 2015-06-17 15:54:22 |
Alberto Aguirre |
description |
libmirprotobuf's ABI has been broken by message design changes, but MIRPROTOBUF_ABI was never bumped, resulting in client crashes.
Existing clients linked to libmirclient8 (like glmark2) are therefore using the old message layouts, however linked to newer versions of libmirprotobuf.so.0 at runtime where those messages are now bigger and different. Allocating these messages on the stack in libmirclient means this causes stack corruption and crashes.
Essentially we've just been breaking the ABI while failing to protect clients by bumping the ABI number.
The problem only becomes visible however when a client is given a newer libmirprotobuf.so.0 while it keeps its older libmirclient.so.8. Such as when be bumped the client ABI recently. |
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
However, to improve the situation a bit we can avoid allocating protobuf messages on the stack and instead use the factory methods provided which will be serviced by an updated libmirprotobuf library. This way at least the message layout is consistent.
We still need to tread carefully when modifying protobuf message definitions. |
|
| 2015-06-17 16:00:27 |
Alberto Aguirre |
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
However, to improve the situation a bit we can avoid allocating protobuf messages on the stack and instead use the factory methods provided which will be serviced by an updated libmirprotobuf library. This way at least the message layout is consistent.
We still need to tread carefully when modifying protobuf message definitions. |
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) |
|
| 2015-06-17 18:24:49 |
PS Jenkins bot |
mir: status |
In Progress |
Fix Committed |
|
| 2015-06-17 19:17:57 |
Launchpad Janitor |
branch linked |
|
lp:mir/0.13 |
|
| 2015-06-18 01:40:32 |
Daniel van Vugt |
summary |
Avoid allocating mir protobuf message objects on the stack |
libmirprotobuf's ABI can be broken when modifying protobuf message definitions |
|
| 2015-06-21 08:01:38 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/wily-proposed/mir |
|
| 2015-06-22 05:26:51 |
Daniel van Vugt |
mir/0.13: status |
Triaged |
Fix Released |
|
| 2015-06-22 05:26:59 |
Daniel van Vugt |
mir/0.13: assignee |
|
Alberto Aguirre (albaguirre) |
|
| 2015-06-22 05:27:11 |
Daniel van Vugt |
bug task added |
|
mir (Ubuntu) |
|
| 2015-06-22 05:27:17 |
Daniel van Vugt |
mir (Ubuntu): status |
New |
Fix Released |
|
| 2015-06-22 05:27:20 |
Daniel van Vugt |
mir (Ubuntu): importance |
Undecided |
High |
|
| 2015-06-22 05:37:56 |
Daniel van Vugt |
branch unlinked |
lp:mir/0.13 |
|
|
| 2015-07-24 02:38:37 |
Daniel van Vugt |
mir: status |
Fix Committed |
Fix Released |
|
