Segfault when running compiled Truffle method.

[Andreas Woess]

Thanks to Bernhard for debugging the crash.
The problem is how you create the materialized frame for the generator.
In the PGenerator constructor you have:
>  MaterializedFrame generatorFrame = new
> DefaultVirtualFrame(frameDescriptor, null,
> PArguments.EMPTY_ARGUMENT).materialize();

Please replace this with:
Truffle.getRuntime().createMaterializedFrame(...) -- Bernhard has sent
you a pull request.
Otherwise the unsafeFrameCast which you have in PArguments is not
correct. The reason it worked in the other case is probably that you
don't have the unsafeFrameCast in GeneratorArguments.getGeneratorFrame().

In general, never create frames yourself, always use the methods in
TruffleRuntime (there's also one for virtual frames nowadays, should you
need it).

- andreas

On 23.01.2014 07:06, Wei Zhang wrote:
> Hi,
>
> I was able to extract a smaller Python program that reproduces crash
> that I reported earlier.
>
> ---------------------------------------------------------
> def generator(n):
>     alist = [j for j in range(n)]
>     for i in range(n):
>         yield list(alist[x] for x in range(i))
>
> for i in generator(10000):
>     result = i
>
> print(i[-1])
> ---------------------------------------------------------
>
> The following command runs the test program shown above and reproduces
> the crash (with the latest commit from ZipPy):
> ./mx.sh python graal/edu.uci.python.test/src/tests/generator-yield-call-with-genexp-test.py
> -OptimizeGeneratorExpressions:false
>
> I can confirm that the generator expression in the yield statement of
> the 'generator' function causes the problem.
> Because if I do not disable -OptimizeGeneratorExpressions options, the
> generator expression semantic is optimized away and it works fine.
>
> As soon as that generator expression is compiled, the crash happens.
> I believe the pattern is that if there is a subscript (list indexing)
> operation in the generator expression, something is wrong after it is
> compiled.
> The program run as expected in interpreter mode.
>
> Hopefully this will make it easier for anybody who wants to take a
> look at the problem.
> Thanks,
> /Wei
>
>
> On Wed, Jan 22, 2014 at 11:39 AM, Wei Zhang <ndrzmansn at gmail.com> wrote:
>> Hi,
>>
>> The error log was dropped by the mailing list.
>> I uploaded it to here:
>> https://db.tt/SnWrKZ3I
>>
>> Thanks,
>> /Wei
>>
>>
>> On Tue, Jan 21, 2014 at 7:41 PM, Wei Zhang <ndrzmansn at gmail.com> wrote:
>>> Hi,
>>>
>>> I keep ran into the same crash when I try run a couple of benchmarks on ZipPy.
>>>
>>> The benchmarks that I have problem with are Python generator
>>> intensive, which relies heavily on MaterializedFrames.
>>> I believe it has something to do with compiled code that accesses
>>> MaterializedFrame.
>>> Sometime, com.oracle.truffle.api.impl.DefaultMaterializedFrame::setInt
>>> shows up in the error message.
>>>
>>> The error message:
>>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGSEGV (0xb) at pc=0x0000000107a06c0b, pid=40193, tid=6403
>>> #
>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)
>>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal mixed mode
>>> bsd-amd64 compressed oops)
>>> # Problematic frame:
>>> # J -1 Graal com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(Lcom/oracle/truffle/api/frame/PackedFrame;Lcom/oracle/truffle/api/Arguments;)Ljava/lang/Object;
>>> (22 bytes) @ 0x0000000107a06c0b [0x0000000107a06800+0x40b]
>>> #
>>> # Failed to write core dump. Core dumps have been disabled. To enable
>>> core dumping, try "ulimit -c unlimited" before starting Java again
>>> #
>>> # An error report file with more information is saved as:
>>> # /Users/zwei/Workspace/zippy/hs_err_pid40193.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> #   http://bugreport.sun.com/bugreport/crash.jsp
>>> #
>>>
>>> The error log is attached.
>>>
>>> The problem can be reproduced with this command:
>>> ./mx.sh --vm server python
>>> graal/edu.uci.python.benchmark/src/benchmarks/bm-ai.py @-esa @-ea
>>>
>>> The latest commits of zippy can be pulled from:
>>> ssh://hg@bitbucket.org/ssllab/zippy
>>>
>>> I'm not sure what would be the best way to debug this from my side,
>>> since it went through the entire compilation phases and crashed at
>>> runtime.
>>> Does anybody has experienced the similar problem?
>>> Any help is appreciated.
>>> Thanks,
>>>
>>> /Wei


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com