daphne-eu / daphne

DAPHNE: An Open and Extensible System Infrastructure for Integrated Data Analysis Pipelines
Apache License 2.0
67 stars 62 forks source link

[Bug] Segmentation Fault after ReadFrame from UDF parameter #643

Open m-birke opened 11 months ago

m-birke commented 11 months ago

Hi, still a problem from readFrame from function parameter.

This does not work with Segmentation fault (core dumped)

import "libutils.daphne";

DATA_PATH = "data/PCF1_tdms_group_0_head.csv";
power = libutils.readPowerFromCycle(DATA_PATH);
//print(power);
time_step = 0.000004;
time = seq(0, time_step*(nrow(power) - 1), time_step);

Adding the commented print(power); statement and it works ...

UDF

def readPowerFromCycle(path: str) {
    group_data = readFrame(path);
    power = as.matrix(group_data[,"Id"]) * as.matrix(group_data[,"Vds"]);
    power = abs(power); // power is always positive
    return power;
}

Here I also encounter the problem that I can't define the return type: def readPowerFromCycle(path: str) -> matrix<f64>{ leads to [error]: Parser error: Function 'readPowerFromCycle' returns different type than specified in the definition

This works

DATA_PATH = "data/PCF1_tdms_group_0_head.csv";

group_data = readFrame(DATA_PATH);

power = as.matrix(group_data[,"Id"]) * as.matrix(group_data[,"Vds"]);
power = abs(power); // power is always positive

time_step = 0.000004;
time = seq(0, time_step*(nrow(power) - 1), time_step);

Also

import "libutils.daphne";
DATA_PATH = "data/PCF1_tdms_group_0_head.csv";
power = libutils.readPowerFromCycle(DATA_PATH);
time_step = 0.000004;
time = time_step*(nrow(power)) - 1;
//print(time);

works, but adding the print(time); statement, again segmentation fault.

MarcusParadies commented 11 months ago

As for the return type bug, at the time the check is performed (in the DSL visitor), we likely cannot know the return type yet ("unknown"), because it is inferred later in the compilation chain. So from my pov the check is valid, but applied too early.

As for the seg fault, I can reproduce it and already digged a little bit into it. It occurs where the generic function templates are being specialized. callOp.setCalleeAttr(specializedFunc.getSymNameAttr()); causes the segfault (actually, in mlir::DictionaryAttr::getValue() const ()), but couldn't really see what is going wrong there.