-
-
Notifications
You must be signed in to change notification settings - Fork 372
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.
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
Experiencing Segfault in NativeCall code for Raku v2024.01-67-g4c86ef7722 (moar v2024.01-6-gedbd26473) #5534
Comments
You can compile the C code with the following line:
It might need minor tuning for your flavor of Linux |
In case it's difficult to build/repro on our systems, can you run it under
valgrind and/or asan and post the output?
…On Tue, Feb 27, 2024 at 11:37 AM Xliff ***@***.***> wrote:
You can compile the C code with the following line:
gcc wd-all-pids.c `pkg-config --cflags libgtop-2.0` -o wd-all-pids `pkg-config --libs libgtop-2.0`
It might need minor tuning for your flavor of Linux
—
Reply to this email directly, view it on GitHub
<#5534 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACOHYUJ2TFOR3TSHOVG2JBLYVYDS5AVCNFSM6AAAAABD4OAXXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGAZDCOBRG4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
This time with sudo... ================================================================================================ This Rakudo version is 2024.01.67.g.4.c.86.ef.7722 built on MoarVM version 2024.01.6.gedbd.26473,
|
I noticed this bit in the first execution, which might be of interest:
...followed by this bit in the second:
I've also noticed that the output for "root" and "exe" are empty, even though they are supposed to be inside a structure with statically sized strings. Why is this? |
By switching the class glibtop_proc_wd is repr<CStruct> is export {
has uint64 $.flags;
has uint32 $.number;
HAS uint8 @.root-a[216] is CArray;
HAS uint8 @.exe-a[216] is CArray;
submethod BUILD {
# @!root[$_] = 0 for 215;
# @!exe[$_] = 0 for 215;
}
method root ($encoding = 'utf8') {
my @r = @!root-a[^216];
nativecast( Str, CArray[uint8].new(@r) );
}
method root-elems {
my @elems;
for ^216 {
if @!root-a[$_] -> $v {
@elems.push: $v;
} else {
last;
}
}
@elems.map({ "\t{ $_ }" }).join("\n");
}
method exe ($encoding = 'utf8') {
my @e = @!exe-a[^216];
nativecast( Str, CArray[uint8].new(@e) );
}
method exe-elems {
my @elems;
for ^216 {
if @!exe-a[$_] -> $v {
@elems.push: $v;
} else {
last;
}
}
@elems.map({ "\t{ $_ }" }).join("\n");
}
} And changing the output line in the program to be: say qq:to/OUTPUT/
Process #{ $p }:
- root:
{ $buf2.root-elems }
- exe:
{ $buf2.exe-elems }
OUTPUT I can get the program to run with no errors. This is telling me that there is something with the For one, why is it that the character data in both @!root and @!exe not filled in with data. The C-version has character data. The Raku version does not and that implies that the CArrays are zero-filled. How did they become zero-filled? I think finding the answer to that question is the key to this issue. Please advise. Thanks! |
@niner is the best resource for NativeCall stuff, but I'll try to take a
look when I reach a pause in the JVM backend work I'm doing right now.
…On Mon, Mar 18, 2024 at 7:04 AM Xliff ***@***.***> wrote:
By switching the glibtop_proc_wd definition to the following:
class glibtop_proc_wd is repr<CStruct> is export {
has uint64 $.flags;
has uint32 $.number;
HAS uint8 @.root-a[216] is CArray;
HAS uint8 @.exe-a[216] is CArray;
submethod BUILD {
# @!root[$_] = 0 for 215;
# @!exe[$_] = 0 for 215;
}
method root ($encoding = 'utf8') {
my @r = @!root-a[^216];
nativecast( Str, ***@***.***) );
}
method root-elems {
my @elems;
for ^216 {
if @!root-a[$_] -> $v {
@elems.push: $v;
} else {
last;
}
}
@elems.map({ "\t{ $_ }" }).join("\n");
}
method exe ($encoding = 'utf8') {
my @e = @!exe-a[^216];
@e.gist.say;
nativecast( Str, ***@***.***) );
}
method exe-elems {
my @elems;
for ^216 {
if @!exe-a[$_] -> $v {
@elems.push: $v;
} else {
last;
}
}
@elems.map({ "\t{ $_ }" }).join("\n");
}
}
—
Reply to this email directly, view it on GitHub
<#5534 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACOHYUK2DAEBHBUEQMITDW3YY3C3LAVCNFSM6AAAAABD4OAXXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBTGYYTINRTHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@MasterDuke: Thanks for the information and the effort! |
AFAIR CArray assumes that it always owns the memory holding the elements and that this memory can be freed via a call to I have a branch for totally revamping NativeCall's memory management but I haven't looked at it for years. It would make all of these assumptions explicitly changeable. |
OK, I think I've come to a sort of a solution. Given the following:
We are expected to get a working Str value. However strings need to be NULL terminated! Of course the construct The fix is to change it to the following: Lo and behold, the program runs to completion, but will still segfault at the end. Running My next problem is with the fact that the strings never hold any values in the Raku version. Compare this:
...versus the C version...
Why is it that the raku CArrays are never filled with data? |
UPDATE -- If I have C allocate the memory for all of the structs then the code runs with no problems. That now begs the question: Why does a Raku allocated structure crash the code? |
I have the following C code:
It will print the path, executable and working directories of every running process, and will output something
that looks like this:
It runs perfectly, with no issues or segfaults.
Here is the standalone version of the NativeCall-enabled raku version:
It does not and will segfault WAY before it gets to pid 1000. What I can get of it looks like this:
Could someone please take a look at this and tell me what I might need to changed?
For the record, the CStructs involved have been SIZE verified against C. That doesn't mean that they are completely
cleared from suspicion.
Thanks in advance to anyone who can take this up!
The text was updated successfully, but these errors were encountered: