Re: [Starpu-devel] [LU factorisation: gdb debug output]

[Maxim Abalenkov <maxim.abalenkov@gmail.com>]

Hello Samuel,

Please find attached the output of the gdb commands that you suggested. It seems there is no node.

—

Best wishes,

Maxim

(gdb) thread 2
[Switching to thread 2 (Thread 0x7fffef4df700 (LWP 27642))]
#0  0x00007ffff73b6213 in _starpu_exponential_backoff (worker=0x7ffff76d0180 
<_starpu_config+1248>) at drivers/driver_common/driver_common.c:328
328             while(delay--)
(gdb) frame 8
#0  0x0000000000000000 in ?? ()
(gdb) print node
No symbol "node" in current context.
(gdb) print local_memory_node
No symbol "local_memory_node" in current context.
(gdb) print descrs[index].node
No symbol "descrs" in current context.

Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 20 Dec 2017, at 14:37, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:

Hello Samuel,

Please find the full gdb backtrace attached.

—

Best wishes,

Maxim

<lu_gdb_thread_apply_all_bt_full.txt>

Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 20 Dec 2017, at 14:35, Samuel Thibault <samuel.thibault@inria.fr> wrote:

Maxim Abalenkov, on mer. 20 déc. 2017 14:30:11 +0100, wrote:

Below is the output of “starpu_machine_display”:

StarPU has found :
4 CPU threads
CPU 0
CPU 1
CPU 2
CPU 3
0 CUDA devices
0 OpenCL devices

topology ... (hwloc logical indexes)
pack 0 core 0 PU 0 CPU 0
PU 1
core 1 PU 2 CPU 1
PU 3
core 2 PU 4 CPU 2
PU 5
core 3 PU 6 CPU 3
PU 7

bandwidth and latency ...
from/to RAM
RAM 0

RAM 0

Ok, so there is no reason why node is 1 in your backtrace.
Are you using the nodes or dyn_nodes field in the codelet structure?

Within

Thread 2 (Thread 0x7fffef4df700 (LWP 11305)):
#0  0x00007ffff31ca860 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff31cbec9 in abort () from /usr/lib/libc.so.6
#2  0x00007ffff31c30bc in __assert_fail_base () from /usr/lib/libc.so.6
#3  0x00007ffff31c3133 in __assert_fail () from /usr/lib/libc.so.6
#4  0x00007ffff73bfafd in _starpu_create_data_request (handle=0x555555a2f750, src_replicate=0x555555a2f848, dst_replicate=0x555555a2f890, handling_node=1, mode=STARPU_W, ndeps=0, is_prefetch=0,
   is_write_invalidation=0) at datawizard/data_request.c:150
#5  0x00007ffff73bbfff in _starpu_create_request_to_fetch_data (handle=0x555555a2f750, dst_replicate=0x555555a2f890, mode=STARPU_W, is_prefetch=0, async=0, callback_func=0x0, callback_arg=0x0)
   at datawizard/coherency.c:634
#6  0x00007ffff73bc751 in _starpu_fetch_data_on_node (handle=0x555555a2f750, node=1, dst_replicate=0x555555a2f890, mode=STARPU_W, detached=0, is_prefetch=0, async=0, callback_func=0x0, callback_arg=0x0)
   at datawizard/coherency.c:754
#7  0x00007ffff73bc8eb in fetch_data (handle=0x555555a2f750, node=1, replicate=0x555555a2f890, mode=STARPU_W) at datawizard/coherency.c:782
#8  0x00007ffff73bd75e in _starpu_fetch_task_input (j=0x555555a5e580) at datawizard/coherency.c:972
#9  0x00007ffff744197c in execute_job_on_cpu (j=0x555555a5e580, worker_task=0x555555a5d900, cpu_args=0x7ffff76d0180 <_starpu_config+1248>, rank=0, perf_arch=0x7ffff76d01c8 <_starpu_config+1320>)

it would be useful to run

gdb> thread 2
gdb> frame 8
gdb> print node
gdb> print local_memory_node
gdb> print descrs[index].node

to make sure where this bogus node is coming from.

Samuel