| 3033
|
|
|
Mathieu Desnoyers |
6 months ago
|
 |
|
| 3032
|
|
|
Mathieu Desnoyers |
6 months ago
|
|
|
| 3031
|
|
|
Mathieu Desnoyers |
6 months ago
|
|
|
| 3030
|
|
|
Michael Jeanson |
6 months ago
|
|
|
| 3029
|
|
|
Mathieu Desnoyers |
6 months ago
|
|
|
| 3028
|
|
|
Jonathan Rajotte |
6 months ago
|
|
|
| 3027
|
|
|
Kienan Stewart |
6 months ago
|
|
|
| 3026
|
|
|
Mathieu Desnoyers |
6 months ago
|
|
|
| 3025
|
|
|
Jérémie Galarneau |
6 months ago
|
|
|
| 3024
|
|
|
Olivier Dion |
8 months ago
|
|
|
| 3023
|
|
|
Olivier Dion |
8 months ago
|
|
|
| 3022
|
|
ustfork: Fix possible race conditions
Assuming that `dlsym(RTLD_NEXT, "symbol")' is invariant for "symbol",
then we could think that memory operations on the `plibc_func' pointers can
be safely done without atomics.
However, consider what would happen if a load to a`plibc_func' pointer
is torn apart by the compiler. Then a thread could see:
1) NULL
2) The stored value as returned by a dlsym() call
3) A mix of 1) and 2)
The same goes for other optimizations that a compiler is authorized to
do (e.g. store tearing, load fusing).
One could question whether such race condition is even possible for the
clone(2) wrapper. Indeed, a thread must be cloned to get into
existence. Therefore, the main thread would always store the value of
`plibc_func' at least once before creating the first sibling thread,
preventing any possible race condition for this wrapper. However, this
assume that the main thread will not call the clone system call directly
before calling the libc wrapper! Thus, to be on the safe side, we do the
same for the clone wrapper.
Fix the race conditions by using the uatomic_read/uatomic_set functions,
on access to `plibc_func' pointers.
Change-Id: Ic4be25983b8836d2b333f367af9c18d2f6b75879
Signed-off-by: Olivier Dion <odion@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
|
Olivier Dion |
8 months ago
|
|
|
| 3021
|
|
|
Mathieu Desnoyers |
10 months ago
|
|
|
| 3020
|
|
|
Michael Jeanson |
10 months ago
|
|
|
| 3019
|
|
|
Michael Jeanson |
10 months ago
|
|
|
| 3018
|
|
|
Michael Jeanson |
10 months ago
|
|
|
| 3017
|
|
|
Michael Jeanson |
10 months ago
|
|
|
| 3016
|
|
|
Michael Jeanson |
10 months ago
|
|
|
| 3015
|
|
Fix: segmentation fault on filter interpretation in "switch" mode
When building the interpreter with `INTERPRETER_USE_SWITCH`, I get the
following crash when interpreting a bytecode:
Program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00007f5789aee443 in lttng_bytecode_interpret (ust_bytecode=0x555dfe90a650, interpreter_stack_data=0x7ffd12615500 "", probe_ctx=0x7ffd12615620,
caller_ctx=0x7ffd126154bc) at lttng-bytecode-interpreter.c:885
#1 0x00007f5789af4da2 in lttng_ust_interpret_event_filter (event=0x555dfe90a580, interpreter_stack_data=0x7ffd12615500 "", probe_ctx=0x7ffd12615620,
event_filter_ctx=0x0) at lttng-bytecode-interpreter.c:2548
#2 0x0000555dfe02d2d4 in lttng_ust__event_probe__tp___the_string (__tp_data=0x555dfe90a580, i=0, arg_i=2, str=0x7ffd12617cfa "hypothec") at ././tp.h:16
#3 0x0000555dfe02cac0 in lttng_ust_tracepoint_cb_tp___the_string (str=0x7ffd12617cfa "hypothec", arg_i=2, i=0)
at /tmp/lttng-master/src/lttng-tools/tests/utils/testapp/gen-ust-nevents-str/tp.h:16
#4 main (argc=39, argv=0x7ffd12615818) at gen-ust-nevents-str.cpp:38
This appears to be caused by `bytecode->data` being used to determine
the `start_pc` address. In my case, `data` is NULL. A quick look around
the code seems to show that this member is not used except during the
transmission of the bytecode.
I am basing the fix on the implementation of START_OP in the default
case which uses `code` in lieu of `data` and can confirm that it fixes
the crash on my end.
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I0773df385b8e90728b60503016dec4b46d902234
|
Jérémie Galarneau |
1 year ago
|
|
|
| 3014
|
|
|
Jérémie Galarneau |
1 year ago
|
|
|
collapse all