profile
viewpoint
Daniel Kolsoi TheDan64 Massachusetts, USA https://immunant.com/blog/2020/01/bitfields/ Software Engineer with a focus in Rust & Python

TheDan64/inkwell 657

It's a New Kind of Wrapper for Exposing LLVM (Safely)

TheDan64/limonite 8

[WIP] Compiler for the Limonite programming language.

immunant/tmux-rs 2

tmux source code

andylincoln/roots 1

GUI II Project Spring 2014

immunant/lil 1

GH mirror/fork of http://runtimeterror.com/rep/lil/wiki?name=Download

immunant/tinycc-rs 1

Fork of the tiny c compiler for use in transpiling via c2rust

TheDan64/advent_of_code 1

Advent of Code 2018+ repo

immunant/bumpalo 0

A fast bump allocation arena for Rust

startedTheDan64/inkwell

started time in 6 hours

created repositorycmclellan22/aoc

Advent of Code 2020

created time in 17 hours

startedTheDan64/inkwell

started time in 20 hours

startedyusuf8ahmed/Wasmite

started time in 21 hours

created repositoryalekratz/adventofcode2020

Advent of Code 2020 solutions

created time in a day

MemberEvent

startedTheDan64/inkwell

started time in a day

starteddatavis-tech/vizhub-issue-tracker

started time in 2 days

created repositorygvanrossum/python-com-azure

created time in 2 days

startedTheDan64/inkwell

started time in 3 days

startedTheDan64/inkwell

started time in 4 days

startedTheDan64/inkwell

started time in 5 days

pull request commentTheDan64/inkwell

fix(module,values) Fix memory leaks

Codecov Report

Merging #225 (7c87321) into master (5e64c01) will decrease coverage by 9.85%. The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #225      +/-   ##
==========================================
- Coverage   62.28%   52.43%   -9.86%     
==========================================
  Files          44       44              
  Lines        4245     4236       -9     
==========================================
- Hits         2644     2221     -423     
- Misses       1601     2015     +414     
Impacted Files Coverage Δ
src/module.rs 75.30% <100.00%> (-13.01%) :arrow_down:
src/comdat.rs 0.00% <0.00%> (-100.00%) :arrow_down:
src/attributes.rs 10.34% <0.00%> (-65.42%) :arrow_down:
src/debug_info.rs 0.00% <0.00%> (-60.14%) :arrow_down:
src/values/call_site_value.rs 43.18% <0.00%> (-52.28%) :arrow_down:
src/values/global_value.rs 77.77% <0.00%> (-21.22%) :arrow_down:
src/values/fn_value.rs 48.50% <0.00%> (-16.17%) :arrow_down:
src/builder.rs 48.69% <0.00%> (-10.40%) :arrow_down:
src/values/instruction_value.rs 69.56% <0.00%> (-10.15%) :arrow_down:
... and 11 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 5e64c01...f3a9aac. Read the comment docs.

Hywan

comment created time in 5 days

PR opened TheDan64/inkwell

fix(module) Fix memory leak inside `get_global_metadata`

Description

This patch fixes a memory leak inside Module::get_global_metadata.

The code was acting like this before:

  1. Allocate a new Vec<LLVMValueRef>,
  2. Get a mutable pointer to it,
  3. Forget the vector,
  4. Fill the vector with LLVMGetNamedMetadataOperands,
  5. Read back the vector as a slice,
  6. Map slice values, and collect them in a newly allocated vector.

Here, the first vector is lost. That's a memory leak.

This patch changes the step 5: Instead of reading the results as a slice, results are read as a vector, the same vector, with the same pointer. That way, the new vec vector will be dropped by Rust nicely.

Compiling and running the documentation of the get_global_metadata method, valgrind gives us the following results:

(before)

==35629== LEAK SUMMARY:
==35629==    definitely lost: 40 bytes in 3 blocks
==35629==    indirectly lost: 0 bytes in 0 blocks
==35629==      possibly lost: 0 bytes in 0 blocks
==35629==    still reachable: 145 bytes in 1 blocks
==35629==         suppressed: 137,663 bytes in 1,484 blocks

(after)

==35805== LEAK SUMMARY:
==35805==    definitely lost: 24 bytes in 2 blocks
==35805==    indirectly lost: 0 bytes in 0 blocks
==35805==      possibly lost: 0 bytes in 0 blocks
==35805==    still reachable: 145 bytes in 1 blocks
==35805==         suppressed: 137,663 bytes in 1,484 blocks
+5 -5

0 comment

1 changed file

pr created time in 5 days

created repositoryMarkMcCaskey/chess

created time in 6 days

startedTheDan64/inkwell

started time in 6 days

startedTheDan64/inkwell

started time in 6 days

issue closedimmunant/c2rust

rust2c?

Hi, are there any plans for a complementary Rust2C utility?

closed time in 7 days

Mis012

issue commentimmunant/c2rust

rust2c?

Hi @Mis012, as a small team, we have to focus on where we think we can have the greatest impact. A Rust2C converter is not something we plan to write. Have you looked at https://github.com/thepowersgang/mrustc?

Mis012

comment created time in 7 days

issue commentTheDan64/inkwell

How to use inkwell

It also seems like llvmenv is having some trouble with maintainers: https://github.com/termoshtt/llvmenv/issues/72

justinfargnoli

comment created time in 7 days

issue openedimmunant/c2rust

rust2c?

Hi, are there any plans for a complementary Rust2C utility?

created time in 7 days

startedcirosantilli/linux-kernel-module-cheat

started time in 8 days

IssuesEvent

issue commentTheDan64/inkwell

How to use inkwell

I'm having trouble finding out how exactly how I resolved it because I resolved this on my old laptop which is currently having issues.

However, @jakevossen5, I think I resolved this by installing the appropriate version of llvm, I'm on macOS so I used brew, and manually set LLVM_SYS_100_PREFIX with the path to brew's installation of llvm.

justinfargnoli

comment created time in 8 days

issue commentTheDan64/inkwell

How to use inkwell

I am having the same issue, are you able to share how you resolved it?

justinfargnoli

comment created time in 8 days

startedTheDan64/inkwell

started time in 8 days

startedTheDan64/inkwell

started time in 9 days

startedcookiecutter/cookiecutter

started time in 9 days

more