Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can't compile on Fedora30 #9

Closed
Whishay opened this issue Jul 30, 2019 · 4 comments
Closed

Can't compile on Fedora30 #9

Whishay opened this issue Jul 30, 2019 · 4 comments

Comments

@Whishay
Copy link

Whishay commented Jul 30, 2019

Hi,
I have install python3-devel on Fedora and still gets the error with both command lines:

#sudo yum install python3-devel
Package python3-devel-3.7.4-1.fc30.x86_64 is already installed.
Dependencies resolved.

#python3 setup.py build
#python3.7m setup.py build
.............................................................................
In file included from ../../libdrgn/python/error.c:4:
../../libdrgn/python/drgnpy.h:9:10: fatal error: Python.h: No such file or directory
.............................................................................
@osandov
Copy link
Owner

osandov commented Jul 30, 2019

Interesting, it works on my Fedora 30 VM. Could you please share the output of:

python3 -c 'import sysconfig; print(sysconfig.get_path("include"))'

And ls of whatever path that tells you.

@Whishay
Copy link
Author

Whishay commented Jul 31, 2019

#python3 -c 'import sysconfig; print(sysconfig.get_path("include"))'
/usr/include/python3.7m

#ls -l /usr/include/python3.7m/Python.h
-rw-r--r--. 1 root root 3554 7月 9 02:03 /usr/include/python3.7m/Python.h

#rpm -qf /usr/include/python3.7m/Python.h
python3-devel-3.7.4-1.fc30.x86_64

@osandov
Copy link
Owner

osandov commented Jul 31, 2019 •
edited

Hm, that's weird. If the file wasn't there, then it shouldn't have made it past the configure step, but clearly it is, so it should work. Can you try doing a build from a clean repo?

git clean -dqfx
python3 setup.py build

And if that doesn't work, can you share the full build output and the output of grep PYTHON_CPPFLAGS build/temp.*/Makefile?

@Whishay
Copy link
Author

Whishay commented Jul 31, 2019

I manually tweaked the Makefile under temp* and it works.
DEFAULT_INCLUDES = -I. -I$(srcdir) -I/usr/include/python3.7m/

Also, it works with a clean build after that.

Thanks osandov.

@Whishay Whishay closed this as completed Jul 31, 2019
ypl-coffee added a commit to ypl-coffee/drgn that referenced this issue Jan 7, 2022
@ypl-coffee
libdrgn: Always fall back to libdwfl ELF relocation
b1285f8 
Simply doing "drgn" segmentation-faults on my machine:

(gdb) bt
 #0  apply_elf_rela_x86_64 (relocating=relocating@entry=0x7fc843650c90, r_offset=0, r_type=2, r_addend=0,
     sym_value=<optimized out>) at ../../libdrgn/arch_x86_64.c:498
 #1  0x00007fc88cbd523b in relocate_elf_section (platform=0x7fc843650c80, shdrnum=59, sh_addrs=0x7fc808000b20,
     symtab_scn=<optimized out>, reloc_scn=0x17614c8, scn=<optimized out>) at ../../libdrgn/debug_info.c:761
 osandov#2  relocate_elf_file (elf=<optimized out>) at ../../libdrgn/debug_info.c:865
 osandov#3  drgn_debug_info_find_sections (module=<optimized out>) at ../../libdrgn/debug_info.c:883
 osandov#4  drgn_debug_info_read_module (load=load@entry=0x7ffea9d70870, dindex_state=0x7ffea9d70810, head=0x163c6b0)
     at ../../libdrgn/debug_info.c:970
 osandov#5  0x00007fc88cbd5474 in drgn_debug_info_update_index._omp_fn.1 () at ../../libdrgn/debug_info.c:1037
 osandov#6  0x00007fc88cb19769 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
 osandov#7  0x00007fc88cb21f00 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
 osandov#8  0x00007fc88cb1f7aa in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
 osandov#9  0x00007fc88dfb7fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
 osandov#10 0x00007fc88dafe4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Always returning NULL in libdrgn/debug_info.c:relocate_elf_file() fixes
the issue.  I don't know, maybe it's a bug in drgn's implementation of
ELF relocation, but add this hack for now.

Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
@osandov osandov mentioned this issue Jun 15, 2023
Closed
imran-kn added a commit to imran-kn/drgn-work that referenced this issue Mar 18, 2024
@imran-kn
contrib: locks: add optimistic-spinner info in rwsem helpers.
96bffa9 
For example:

python3 -m drgn -s vmlinux -c vmcore-writer-reader-reader-reader contrib/locks.py rwsem --spinner-callstack ffffffffc03083c0
rwsem: ffffffffc03083c0 has 1 spinners and their call-stack is as follows:

call stack for pid: 239
 #0  __read_once_size (./include/linux/compiler.h:268:2)
 osandov#1  arch_atomic64_read (./arch/x86/include/asm/atomic64_64.h:22:9)
 osandov#2  atomic64_read (./include/asm-generic/atomic-instrumented.h:837:9)
 osandov#3  atomic_long_read (./include/asm-generic/atomic-long.h:28:9)
 osandov#4  rwsem_owner_flags (kernel/locking/rwsem.c:298:24)
 osandov#5  rwsem_spin_on_owner (kernel/locking/rwsem.c:737:9)
 osandov#6  rwsem_optimistic_spin (kernel/locking/rwsem.c:812:17)
 osandov#7  rwsem_down_read_slowpath (kernel/locking/rwsem.c:1018:6)
 osandov#8  __down_read_killable (kernel/locking/rwsem.c:1366:14)
 osandov#9  down_read_killable (kernel/locking/rwsem.c:1532:6)
 osandov#10 0xffffffffc030622c
.................

Signed-off-by: Imran Khan <imran.f.khan@oracle.com>
imran-kn added a commit to imran-kn/drgn-work that referenced this issue Mar 18, 2024
@imran-kn
contrib: locks: add optimistic-spinner info in mutex helpers.
62add44 
For example:
python3 -m drgn -s vmlinux -c vmcore-1 contrib/locks.py mutex --spinner-callstack ffffffffc02af340
mutex: ffffffffc02af340 has 4 spinners and their call-stack is as follows:

call stack for pid: 250
 #0  __read_once_size (./include/linux/compiler.h:268:2)
 osandov#1  osq_lock (kernel/locking/osq_lock.c:137:10)
 osandov#2  mutex_optimistic_spin (kernel/locking/mutex.c:667:8)
 osandov#3  __mutex_lock_common (kernel/locking/mutex.c:971:6)
 osandov#4  __mutex_lock (kernel/locking/mutex.c:1109:9)
 osandov#5  0xffffffffc02ad045
 ......................

call stack for pid: 251
 #0  __read_once_size (./include/linux/compiler.h:268:2)
 osandov#1  osq_lock (kernel/locking/osq_lock.c:137:10)
 osandov#2  mutex_optimistic_spin (kernel/locking/mutex.c:667:8)
 osandov#3  __mutex_lock_common (kernel/locking/mutex.c:971:6)
 osandov#4  __mutex_lock (kernel/locking/mutex.c:1109:9)
 osandov#5  0xffffffffc02ad045
 .....................

call stack for pid: 248
 #0  __read_once_size (./include/linux/compiler.h:268:2)
 osandov#1  osq_lock (kernel/locking/osq_lock.c:137:10)
 osandov#2  mutex_optimistic_spin (kernel/locking/mutex.c:667:8)
 osandov#3  __mutex_lock_common (kernel/locking/mutex.c:971:6)
 osandov#4  __mutex_lock (kernel/locking/mutex.c:1109:9)
 osandov#5  0xffffffffc02ad045
.....................

call stack for pid: 249
 #0  __read_once_size (./include/linux/compiler.h:268:2)
 osandov#1  arch_atomic64_read (./arch/x86/include/asm/atomic64_64.h:22:9)
 osandov#2  atomic64_read (./include/asm-generic/atomic-instrumented.h:837:9)
 osandov#3  atomic_long_read (./include/asm-generic/atomic-long.h:28:9)
 osandov#4  __mutex_owner (kernel/locking/mutex.c:75:32)
 osandov#5  mutex_spin_on_owner (kernel/locking/mutex.c:566:9)
 osandov#6  mutex_optimistic_spin (kernel/locking/mutex.c:683:8)
 osandov#7  __mutex_lock_common (kernel/locking/mutex.c:971:6)
 osandov#8  __mutex_lock (kernel/locking/mutex.c:1109:9)
 osandov#9  0xffffffffc02ad045
....................

Signed-off-by: Imran Khan <imran.f.khan@oracle.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@osandov @Whishay