Unfortunatelly, I still could not make a simple case to reproduce the issue.
However, we observed the same issue happen several times and core dump
generated in the application these days.
I used gdb to show the disassemble:
(gdb) disassemble /rm
Dump of assembler code for function rpyvmprof_f_pypy_rrr:
0x00007f27ff816b40 <+0>: 41 57 push %r15
0x00007f27ff816b42 <+2>: 41 56 push %r14
0x00007f27ff816b44 <+4>: 41 55 push %r13
0x00007f27ff816b46 <+6>: 41 54 push %r12
0x00007f27ff816b48 <+8>: 49 89 d5 mov %rdx,%r13
0x00007f27ff816b4b <+11>: 55 push %rbp
0x00007f27ff816b4c <+12>: 53 push %rbx
0x00007f27ff816b4d <+13>: 49 89 f4 mov %rsi,%r12
0x00007f27ff816b50 <+16>: 48 89 fb mov %rdi,%rbx
0x00007f27ff816b53 <+19>: 48 83 ec 18 sub $0x18,%rsp
0x00007f27ff816b57 <+23>: e8 74 ee b6 00 callq 0x7f28003859d0
<pypy_g_stack_check___>
0x00007f27ff816b5c <+28>: 48 83 3d 1c 66 94 02 00 cmpq
$0x0,0x294661c(%rip) # 0x7f280215d180 <pypy_g_ExcData>
0x00007f27ff816b64 <+36>: 0f 85 36 01 00 00 jne
0x7f27ff816ca0 <rpyvmprof_f_pypy_rrr+352>
0x00007f27ff816b6a <+42>: 66 48 8d 3d 8e b3 2f 01 data16 lea
0x12fb38e(%rip),%rdi # 0x7f2800b11f00
0x00007f27ff816b72 <+50>: 66 66 48 e8 6e ec cf ff data16 data16 callq
0x7f27ff5157e8 <__tls_get_addr@plt>
0x00007f27ff816b7a <+58>: f6 43 04 01 testb $0x1,0x4(%rbx)
0x00007f27ff816b7e <+62>: 48 8b 68 30 mov 0x30(%rax),%rbp
=> 0x00007f27ff816b82 <+66>: 4c 8b 75 48 mov 0x48(%rbp),%r14
0x00007f27ff816b86 <+70>: 0f 85 4c 01 00 00 jne
0x7f27ff816cd8 <rpyvmprof_f_pypy_rrr+408>
0x00007f27ff816b8c <+76>: f6 45 04 01 testb $0x1,0x4(%rbp)
0x00007f27ff816b90 <+80>: 4c 89 73 18 mov %r14,0x18(%rbx)
0x00007f27ff816b94 <+84>: 0f 85 2e 01 00 00 jne
0x7f27ff816cc8 <rpyvmprof_f_pypy_rrr+392>
0x00007f27ff816b9a <+90>: 48 89 5d 48 mov %rbx,0x48(%rbp)
0x00007f27ff816b9e <+94>: 48 89 de mov %rbx,%rsi
0x00007f27ff816ba1 <+97>: 48 89 ef mov %rbp,%rdi
0x00007f27ff816ba4 <+100>: e8 f7 ae fd ff callq 0x7f27ff7f1aa0
<pypy_g_ExecutionContext_call_trace>
0x00007f27ff816ba9 <+105>: 4c 8b 3d d0 65 94 02 mov
0x29465d0(%rip),%r15 # 0x7f280215d180 <pypy_g_ExcData>
0x00007f27ff816bb0 <+112>: 4c 89 ea mov %r13,%rdx
0x00007f27ff816bb3 <+115>: 4d 85 ff test %r15,%r15
0x00007f27ff816bb6 <+118>: 49 89 dd mov %rbx,%r13
0x00007f27ff816bb9 <+121>: 49 89 ee mov %rbp,%r14
0x00007f27ff816bbc <+124>: 0f 84 5e 03 00 00 je
0x7f27ff816f20 <rpyvmprof_f_pypy_rrr+992>
0x00007f27ff816bc2 <+130>: 48 63 15 63 0e 95 02 movslq
0x2950e63(%rip),%rdx # 0x7f2802167a2c <pypydtcount>
And the content of regesters:
(gdb) i r
rax 0x468917e8 1183389672
rbx 0x4df8bd0 81759184
rcx 0x7000000000000a60 8070450532247931488
rdx 0x14 20
rsi 0x0 0
rdi 0x7f2800b11f00 139809787027200
rbp 0x0 0x0
rsp 0x4688cc40 0x4688cc40
r8 0x7f2800f57d80 139809791507840
r9 0x100000000 4294967296
r10 0x4df8b80 81759104
r11 0x3472a7aeee 225261891310
r12 0x0 0
r13 0x0 0
r14 0x0 0
r15 0x4688ce50 1183370832
rip 0x7f27ff816b82 0x7f27ff816b82 <rpyvmprof_f_pypy_rrr+66>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x63 99
gs 0x0 0
I searched for "rpyvmprof_f" and found the matched py file in pypy
"rpython/rlib/rvmprof/cintf.py".
Is this the matched code where the issue happened? And what does these code
do?
On Mon, Aug 31, 2015 at 5:41 PM, Yicong Huang <hengha....@gmail.com> wrote:
> I am not sure whether it is a bug of pypy.
> I tried extracting the code from the whole programme, but it worked
> correctly.
>
> rpython_startup_code();
> int res = pypy_setup_home("/usr/local/pypy/libpypy-c.so", 1);
> char *b = "import
> sys\nsys.path.insert(0,'job_runtime/lib/python2.7/site-packages/udf')\00010260";
> pypy_execute_source(b);
>
> I will do some further experiments. And if there are any methods to debug,
> I could follow.
>
> Thanks!
>
>
> On Mon, Aug 31, 2015 at 5:15 PM, Maciej Fijalkowski <fij...@gmail.com>
> wrote:
>
>> Can you please file a bug on either pypy or vmprof-python?
>>
>> On Mon, Aug 31, 2015 at 11:00 AM, Yicong Huang <hengha....@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > We observed the program was cored dump. And examing the core file, we
>> found
>> > the call stack:
>> >
>> > #0 0x00007f26487e6b82 in rpyvmprof_f_pypy_rrr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #1 0x00007f26494a797a in rpyvmprof_t_pypy_rrr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #2 0x00007f26487a1ad4 in
>> > pypy_g_appexec___src__glob___________________import_sys () from
>> > /usr/local/pypy/libpypy-c.so
>> > #3 0x00007f26486f980b in pypy_g.pypy_execute_source () from
>> > /usr/local/pypy/libpypy-c.so
>> > #4 0x00007f26486f9994 in pypy_g_pypy_execute_source_ptr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #5 0x00007f26484e6f42 in pypy_execute_source_ptr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #6 0x00007f26484e6d82 in pypy_execute_source () from
>> > /usr/local/pypy/libpypy-c.so
>> > ...
>> >
>> > And debugging the core file, the char* buffer passed to
>> > pypy_execute_source() was:
>> > (gdb) print pyExBuffer
>> > $1 = "import
>> >
>> sys\nsys.path.insert(0,'job_runtime/lib/python2.7/site-packages/udf')\000/1440989742122"...
>> >
>> > The code was to add a directory to sys.path().
>> > The error was not reproduceable by extracting the piece of code from the
>> > whole programme, and I've no ideas why the segmentation fault happened.
>> >
>> > Does anyone knows what the function "rpyvmprof_f_pypy_rrr ()" did? And
>> are
>> > there any methods to debug and found out the cause?
>> >
>> >
>> >
>> > _______________________________________________
>> > pypy-dev mailing list
>> > pypy-dev@python.org
>> > https://mail.python.org/mailman/listinfo/pypy-dev
>> >
>>
>
>
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
