libqmi-glib,device: make sure transaction ids are unique
Otherwise, we may end up with transactions timing out and segfaulting as they
aren't found in the tracking table (e.g. if the replacing transaction finishes
before the timeout of the replaced transaction is fired off).
==573== Command: /usr/libexec/qmi-proxy --no-exit --verbose
==573== Parent PID: 567
==573==
==573== Invalid write of size 8
==573== at 0x4E9A07A: transaction_timed_out (qmi-device.c:248)
==573== by 0x5D24EB2: ??? (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x5D24439: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x5D247EF: ??? (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x5D24B11: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x40139D: main (qmi-proxy.c:220)
==573== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==573==
==573==
==573== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==573== Access not within mapped region at address 0x10
==573== at 0x4E9A07A: transaction_timed_out (qmi-device.c:248)
==573== by 0x5D24EB2: ??? (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x5D24439: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x5D247EF: ??? (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x5D24B11: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.5000.1)
==573== by 0x40139D: main (qmi-proxy.c:220)
==573== If you believe this happened as a result of a stack
==573== overflow in your program's main thread (unlikely but
==573== possible), you can try to increase the size of the
==573== main thread stack using the --main-stacksize= flag.
==573== The main thread stack size used in this run was 8388608.
(cherry picked from commit 0148e81aa978a5d94ef2e9ddf8adfefa7ce2ef3f)
1 file changed
