profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mxxo/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

dranikpg/rcin 3

Rust cin like input

mxxo/gmsh-sys 3

Unofficial Rust bindings to the Gmsh API

mxxo/dose2gmsh 2

Visualize EGSnrc 3ddose files in Gmsh

mxxo/egsParser 1

Parser for Electron-Gamma-Shower input files using Haskell

mxxo/alice-rs 0

Analyze the public data from the CERN base ALICE collaboration with Rust

mxxo/approx 0

Approximate floating point equality comparisons and assertions

mxxo/arcs 0

A Rust CAD System

mxxo/babby-graphics 0

web gl time

mxxo/bitvec 0

A crate for managing memory bit by bit

mxxo/cargo-geiger 0

Detects usage of unsafe Rust in a Rust crate and its dependencies.

startedhaeginh/TetCal

started time in 4 hours

PR opened qnzhou/MshIO

Document PhysicalGroups

This PR adds some documentation for the PhysicalGroups support added in #3.

+18 -2

0 comment

1 changed file

pr created time in 10 days

push eventmxxo/MshIO

Max Orok

commit sha 1dd701f286d67d5977afca01c46540daa541832b

Document PhysicalGroups

view details

push time in 10 days

create barnchmxxo/MshIO

branch : pg-doc

created branch time in 10 days

push eventmxxo/EGSnrc

Max Orok

commit sha e83c3dbd422b07ad8c09104d5165ed8762fe0286

Improve octree search for overlapping elements Rarely (~1.5% for a 600,000 element mesh), part of an element may be contained within an octant but not counted as a bounded element because none of the nodes or centroid are within the octant. The previous implementation wrongly considered these points as outside (-1), while the brute force method disagreed and found the correct element. This issue was overcome by not immediately halting the search, but by storing the size of the largest tetrahedral edge and comparing it to the bounding box of the octant searched so far. If the search fails in the most likely octant, its siblings are searched and then the parent's siblings, etc, expanding the search area by moving up the octree. Only when this "largest possible tetrahedron search" is completed, does the octree conclude the point is indeed not inside the mesh.

view details

push time in 11 days

push eventmxxo/EGSnrc

Max Orok

commit sha 7c45025d67b68dcc8c026647f1ea45055915eaba

Improve egs_mesh initialization warnings

view details

Max Orok

commit sha 3a12692346da70a7db6ee06817fe807855dbc742

Fix normal calculation region in howfar_exterior

view details

Max Orok

commit sha d5b0c1acc1d5fddf100aba446e6003a49ad8fa00

Set mesh labels and boundary tolerance from input

view details

Max Orok

commit sha 72962dcf47bb5b12a741992d7303a5d4a86958f4

Silence int <-> size_t comparison warning We've already checked the size_t can fit into an int at the start of the constructor.

view details

Max Orok

commit sha 197aea05c33d567cdda001d7bb07da4202d22492

Fix EGS_Mesh normals for egs_view EGS_Mesh wasn't displaying properly, because the normals weren't being set correctly.

view details

Max Orok

commit sha 6f29abd95e32c0c074e7e28b011eb11234a16ff2

Check the output file was actually opened

view details

Max Orok

commit sha ff05c8a01f9b9e2fd1aa75b0a90119ffd121d9db

Make output file name based on input and msh name

view details

Max Orok

commit sha 1a67bb471d2e591f200bd8cb9d1dc270d1581955

Fix msh output for EGS_Mesh in egs_genvelope The implementation is somewhat hacky but is intended for the most common case: wrapping an EGS_Mesh in a single simple, base geometry (e.g. some CAD model in an air box). This removes the requirement for users to mesh a bounding box at the Gmsh stage.

view details

Max Orok

commit sha e868fa07ff9d68bd7685b7a693fd891f950e2582

(WIP) Add octree implementation

view details

Max Orok

commit sha 34a3a13b166db7a5a498c339e5516e1dc7ab62a7

Start refactoring octree * Count overlapping elements in both bounding boxes * Better octant numbering for reduced lookup cost * Helper functions galore

view details

push time in 11 days

issue commentnrc-cnrc/EGSnrc

Default to high resolution random number generators

Perhaps it's worth mentioning ranlux++ as another potential choice? Greatly improved performance over plain ranlux but still "suitable for use in the most demanding Monte Carlo calculations". There exists a portable C++ implementation that was recently added to ROOT: https://arxiv.org/abs/2106.02504

mainegra

comment created time in a month

push eventmxxo/EGSnrc

Max Orok

commit sha ff05c8a01f9b9e2fd1aa75b0a90119ffd121d9db

Make output file name based on input and msh name

view details

Max Orok

commit sha 1a67bb471d2e591f200bd8cb9d1dc270d1581955

Fix msh output for EGS_Mesh in egs_genvelope The implementation is somewhat hacky but is intended for the most common case: wrapping an EGS_Mesh in a single simple, base geometry (e.g. some CAD model in an air box). This removes the requirement for users to mesh a bounding box at the Gmsh stage.

view details

push time in a month

push eventmxxo/EGSnrc

Max Orok

commit sha 8f21fa5e8f051cc29926ac57567e68cf0e5d0f07

Fix msh file output for EGS_Mesh in egs_genvelope The implementation is somewhat hacky but is intended for the most common case: wrapping an EGS_Mesh in a box (e.g. some CAD shape in an air box). This removes the requirement for users to mesh an box at the Gmsh stage.

view details

push time in a month

create barnchmxxo/EGSnrc

branch : mesh-envelope

created branch time in a month

push eventmxxo/EGSnrc

Max Orok

commit sha 7c45025d67b68dcc8c026647f1ea45055915eaba

Improve egs_mesh initialization warnings

view details

Max Orok

commit sha 3a12692346da70a7db6ee06817fe807855dbc742

Fix normal calculation region in howfar_exterior

view details

Max Orok

commit sha d5b0c1acc1d5fddf100aba446e6003a49ad8fa00

Set mesh labels and boundary tolerance from input

view details

Max Orok

commit sha 72962dcf47bb5b12a741992d7303a5d4a86958f4

Silence int <-> size_t comparison warning We've already checked the size_t can fit into an int at the start of the constructor.

view details

Max Orok

commit sha 197aea05c33d567cdda001d7bb07da4202d22492

Fix EGS_Mesh normals for egs_view EGS_Mesh wasn't displaying properly, because the normals weren't being set correctly.

view details

Max Orok

commit sha 6f29abd95e32c0c074e7e28b011eb11234a16ff2

Check the output file was actually opened

view details

push time in a month

issue commentbacktrace-labs/slitter

Check for pointers that appear twice in the same magazine of freed objects

Is there a potential issue here because allocations in a loop will be close together? Barring an issue with my quick implementation here, nearby allocations all get hashed with multiply-shift to the same value:

use slitter::{Class, ClassConfig};
use std::alloc::Layout;

struct C {
    a: i16,
    b: i32,
}

/// Hash `x` with seed `a` using multiply-shift to (2^11) 2048 bins.
fn hash(x: usize, a: usize) -> usize {
    a.wrapping_mul(x) >> (usize::BITS - 11)
}

fn main() {
    let class_allocator = Class::new(ClassConfig {
        name: None,
        layout: Layout::new::<C>(),
        zero_init: true,
        mapper_name: None,
    })
    .unwrap();

    let seed = 1265; // 2^11 = 2048 / golden ratio ~= 1265
    for _ in 0..30 {
        let alloc = class_allocator.allocate().unwrap();
        println!("allocated {:p}, hashed to {:?}", alloc, hash(alloc.as_ptr() as usize, seed));
    }
}
allocated 0x7f2b80000000, hashed to 19
allocated 0x7f2b800000f0, hashed to 19
allocated 0x7f2b800000e8, hashed to 19
...
allocated 0x7f2b80000010, hashed to 19
pkhuong

comment created time in a month

issue closedbbqsrc/cargo-proc-macro

Output workspace structure

Investigate potential changes to the output workspace structure to make program output match exemplary proc-macros like inventory (see motivating discussion here).

closed time in a month

mxxo

issue commentbbqsrc/cargo-proc-macro

Output workspace structure

Hey that's great! Guess I'll close this 😄

mxxo

comment created time in a month

issue commentbacktrace-labs/slitter

Check for pointers that appear twice in the same magazine of freed objects

And I guess if there's a collision we could then fall back to a slower, fully accurate method to confirm ensuring there's no false positives overall.

pkhuong

comment created time in a month

issue commentbacktrace-labs/slitter

Check for pointers that appear twice in the same magazine of freed objects

Did you have something like this (naive impl) in mind?

diff --git a/src/magazine.rs b/src/magazine.rs
index 63c73c6..e99ba3e 100644
--- a/src/magazine.rs
+++ b/src/magazine.rs
@@ -398,7 +398,20 @@ impl crate::class::ClassInfo {
 
         if mag.is_empty() {
             self.rack.release_empty_magazine(mag);
-        } else if mag.is_full() {
+            return;
+        }
+
+        let mut set = std::collections::HashSet::new();
+        for i in 0..mag.0.len() {
+            if let Some(alloc) = mag.0.nth(i) {
+                let unique = set.insert(alloc.get().as_ptr());
+                if !unique {
+                    panic!("double free of {:p}", alloc.get().as_ptr());
+                }
+            }
+        }
+
+        if mag.is_full() {
             self.full_mags.push(mag);
         } else {
             self.partial_mags.push(mag);

This catches the following double free:

use slitter::{Class, ClassConfig};
use std::alloc::Layout;

struct C {
    a: i16,
    b: i32,
}

fn main() {
    let class_allocator = Class::new(ClassConfig {
        name: None,
        layout: Layout::new::<C>(),
        zero_init: true,
        mapper_name: None,
    })
    .unwrap();

    let alloc = class_allocator.allocate().unwrap();
    let double_free = alloc;

    class_allocator.release(alloc);
    class_allocator.release(double_free);
}
thread 'main' panicked at 'double free of 0x7f1f80000000', /home/max/projects/slitter/src/magazine.rs:409:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
Aborted (core dumped)

When check-contracts is enabled this is caught already:

thread 'main' panicked at 'Pre-condition of release violated: Released blocks must match the class and not double-free.: debug_allocation_map :: mark_released(self, & block).is_ok()', /home/max/projects/slitter/src/individual.rs:54:16
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
pkhuong

comment created time in a month

push eventmxxo/EGSnrc

Max Orok

commit sha 9ec4a433a21a0fffa73665a0d43c5b97117ea209

Add "good enough" dose scoring for now Off by a constant factor (getFluence?) compared to egs_dose_scoring output -- enough to compare, will soon transition to maintaining a local EGS_XYZGeometry to use with our own egs_dose_scoring object.

view details

push time in 2 months

create barnchmxxo/iris-hep.github.io-source

branch : max-orok-presentation

created branch time in 2 months

push eventmxxo/EGSnrc

Max Orok

commit sha dbe8df820fe44355422ba6c279272667568f484f

Fix calculated values by calling setHistory Otherwise, current_ncase in EGS_Scoring_Array never gets incremented.

view details

Max Orok

commit sha 2524f23a2fb6a21ecc5dd77ed478a9084741fdd8

Fix classification of boundary particles on grid Before this change, results showed a large buildup of deposited energy for a single section of boundary elements. There is still a discrepancy with how the dose grid calculates isWhere compared to EGS_XYZGeometry, which will be addressed in further commits.

view details

push time in 2 months

pull request commentroot-project/root

[ntuple] (WIP) RNTuple S3 object store backend

Davix apparently also supports Azure to some degree: https://davix.web.cern.ch/davix/docs/master/cloud-support.html#microsoft-azure. If there's an implementation that works for S3, Azure support might be as straightforward as swapping out the S3 setup steps for Azure setup. But this is scope creep for this PR and I don't know if Azure is a desired feature for users, etc.

mxxo

comment created time in 2 months

create barnchmxxo/EGSnrc

branch : dose-grid

created branch time in 2 months

PR opened nrc-cnrc/EGSnrc

Fix out-of-bounds read in `egs_view` by making region arrays the same size

After compiling egs_view with asan support, there was a buffer overflow error encountered opening tutor7pp/test1.egsinp.

It was traced back to the memcpy call in ImageWindow::paintEvent:

==26122==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffe71889e40 at pc 0x7f543595ece0 bp 0x7ffe71889da0 sp 0x7ffe71889548
READ of size 400 at 0x7ffe71889e40 thread T0
    #0 0x7f543595ecdf  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x99cdf)
    #1 0x55dc3acdbb15 in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
    #2 0x55dc3acdbb15 in ImageWindow::paintEvent(QPaintEvent*) /home/max/projects/EGSnrc/HEN_HOUSE/egs++/view/image_window.cpp:348
    #3 0x7f5434f86047 in QWidget::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x193047)

The issue is that memcpy will always copy sizeof(lastRegions) bytes, into the array regions, but before this change regions could be shorter than lastRegions, leading to a buffer overflow. After this change, maxreg is always set to N_REG_MAX, the length of lastRegions.

This effectively reverts part of 246ee26306a3f288fc5c1631b9751e491485b9e7, where the size of regions was changed to scale the region list when the window was resized (perhaps there is a better resolution that keeps this feature, I thought I would try the simplest resolution for now).

Reproduction

Compile egs_view with asan support by uncommenting the following lines: https://github.com/nrc-cnrc/EGSnrc/blob/a6fc389c6465c949645380976f38a013a639759c/HEN_HOUSE/egs%2B%2B/view/view.pro#L91-L94

$ cd $EGS_HOME
$ egs_view tutor7pp/test1.egsinp

<details> <summary> Full debug log and asan output </summary>

$ egs_view tutor7pp/test1.egsinp 
In init()
QObject::connect: No such signal QLineEdit::lostFocus()
QObject::connect:  (sender name:   'fileName')
QObject::connect:  (receiver name: 'save image')
In loadInput(), reloading is 0
GeometryViewControl::loadInput: Clearing previous geometries...
GeometryViewControl::loadInput: Clearing previous ausgab objects...
GeometryViewControl::loadInput: Reading input file...
GeometryViewControl::loadInput: Creating the geometry...
Got 0 user defined colors
In setGeometry(), geometry name is slab
 center: (0,0,0.05)
 xmin: (-5,-5,0)
 xmax: (5,5,0.1)
 nx=512 ny=512 nnx=512 nny=512 nxr=1 nyr=1
GeometryViewControl::loadInput: Processing ausgab objects...
EGS_ObjectFactory::createObjects(): the input is not of type ausgab object definition and also does not have items of this type
 nx=512 ny=512 nnx=128 nny=128 nxr=4 nyr=4
In resizeEvent(): size is 512 512 old size is: -1 -1 shown: 0
 nx=512 ny=512 nnx=128 nny=256 nxr=4 nyr=2
 nx=512 ny=512 nnx=512 nny=512 nxr=1 nyr=1
=================================================================
==26122==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffe71889e40 at pc 0x7f543595ece0 bp 0x7ffe71889da0 sp 0x7ffe71889548
READ of size 400 at 0x7ffe71889e40 thread T0
    #0 0x7f543595ecdf  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x99cdf)
    #1 0x55dc3acdbb15 in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
    #2 0x55dc3acdbb15 in ImageWindow::paintEvent(QPaintEvent*) /home/max/projects/EGSnrc/HEN_HOUSE/egs++/view/image_window.cpp:348
    #3 0x7f5434f86047 in QWidget::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x193047)
    #4 0x7f5434f4783b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15483b)
    #5 0x7f5434f4f103 in QApplication::notify(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15c103)
    #6 0x7f54341c98d7 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x28a8d7)
    #7 0x7f5434f7f199 in QWidgetPrivate::sendPaintEvent(QRegion const&) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x18c199)
    #8 0x7f5434f7f759 in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x18c759)
    #9 0x7f5434f56dfd  (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x163dfd)
    #10 0x7f5434f570a4  (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x1640a4)
    #11 0x7f5434f6e67e in QWidgetPrivate::syncBackingStore() (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x17b67e)
    #12 0x7f5434f861b7 in QWidget::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x1931b7)
    #13 0x7f5434f4783b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15483b)
    #14 0x7f5434f4f103 in QApplication::notify(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15c103)
    #15 0x7f54341c98d7 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x28a8d7)
    #16 0x7f5434f57ec7  (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x164ec7)
    #17 0x7f5434f58b86  (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x165b86)
    #18 0x7f5434f703c6 in QWidget::repaint(QRect const&) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x17d3c6)
    #19 0x7f5434f7042b in QWidget::repaint() (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x17d42b)
    #20 0x55dc3ace3d76 in ImageWindow::drawResults(RenderResults, RenderParameters) /home/max/projects/EGSnrc/HEN_HOUSE/egs++/view/image_window.cpp:648
    #21 0x55dc3acef5ef in ImageWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) .moc/linux/moc_image_window.cpp:203
    #22 0x7f54341f90c1 in QObject::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2ba0c1)
    #23 0x7f5434f8675a in QWidget::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x19375a)
    #24 0x7f5434f4783b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15483b)
    #25 0x7f5434f4f103 in QApplication::notify(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15c103)
    #26 0x7f54341c98d7 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x28a8d7)
    #27 0x7f54341cc04c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x28d04c)
    #28 0x7f5434223262  (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2e4262)
    #29 0x7f54314eb536 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c536)
    #30 0x7f54314eb76f  (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c76f)
    #31 0x7f54314eb7fb in g_main_context_iteration (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c7fb)
    #32 0x7f543422288e in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2e388e)
    #33 0x7f54341c7909 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x288909)
    #34 0x7f54341d09b3 in QCoreApplication::exec() (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2919b3)
    #35 0x55dc3ac1ed33 in main /home/max/projects/EGSnrc/HEN_HOUSE/egs++/view/main.cpp:137
    #36 0x7f54331e5b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #37 0x55dc3ac1f639 in _start (/home/max/projects/EGSnrc/HEN_HOUSE/bin/linux/egs_view+0x1f639)

Address 0x7ffe71889e40 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x99cdf) 
Shadow bytes around the buggy address:
  0x10004e309370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004e309380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004e309390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004e3093a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004e3093b0: 00 00 00 00 00 00 00 00 ca ca ca ca 00 00 00 00
=>0x10004e3093c0: 00 00 00 00 00 00 00 00[cb]cb cb cb 00 00 00 00
  0x10004e3093d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004e3093e0: 00 00 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2 f8 f2
  0x10004e3093f0: f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
  0x10004e309400: f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
  0x10004e309410: f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==26122==ABORTING

</details>

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchmxxo/EGSnrc

branch : view-oob-read

created branch time in 2 months

Pull request review commentnrc-cnrc/EGSnrc

Fix some memory leaks in egs++ reported by AddressSanitizer

 EGS_Object *EGS_ObjectFactory::createObjects(EGS_Input *i,         if (!o) egsWarning("EGS_ObjectFactory::createObjects(): an object "                                "with the name %s does not exist\n",sought_object.c_str());     }+    delete input;

input is allocated here by takeInputItem but never deallocated. https://github.com/nrc-cnrc/EGSnrc/blob/3e0db683e48a328b8fede9e7756e0deb693fbf9e/HEN_HOUSE/egs%2B%2B/egs_object_factory.cpp#L162-L163 https://github.com/nrc-cnrc/EGSnrc/blob/3e0db683e48a328b8fede9e7756e0deb693fbf9e/HEN_HOUSE/egs%2B%2B/egs_input.cpp#L226-L237

mxxo

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentnrc-cnrc/EGSnrc

Fix some memory leaks in egs++ reported by AddressSanitizer

 EGS_AdvancedApplication::~EGS_AdvancedApplication() {     if (n_rng_buffer > 0) {         delete [] rng_buffer;     }+    if (nmed > 0) {

Interpolators are allocated if nmed > 0 in EGS_AdvanchedApplication::helpInit but not deallocated.https://github.com/nrc-cnrc/EGSnrc/blob/3e0db683e48a328b8fede9e7756e0deb693fbf9e/HEN_HOUSE/egs%2B%2B/egs_advanced_application.cpp#L661-L672

mxxo

comment created time in 2 months

Pull request review commentnrc-cnrc/EGSnrc

Fix some memory leaks in egs++ reported by AddressSanitizer

 int EGS_AdvancedApplication::helpInit(EGS_Input *transportp, bool do_hatch) {             the_xoptions->iedgfl = 2;             relax.setOption(1,"eadl");         }+        delete transportp;

transportp is allocated by getInputItem but wasn't freed. https://github.com/nrc-cnrc/EGSnrc/blob/3e0db683e48a328b8fede9e7756e0deb693fbf9e/HEN_HOUSE/egs%2B%2B/egs_advanced_application.cpp#L435 https://github.com/nrc-cnrc/EGSnrc/blob/3e0db683e48a328b8fede9e7756e0deb693fbf9e/HEN_HOUSE/egs%2B%2B/egs_input.cpp#L245-L254

mxxo

comment created time in 2 months

PullRequestReviewEvent

PR opened nrc-cnrc/EGSnrc

Fix some memory leaks in egs++ reported by AddressSanitizer

I compiled egs++ and tutor7pp with g++ -fsanitize=address -static-libasan and ran tutor7pp -i tracks1.egsinp -p tutor_data.pegs4dat. There were a few small memory leaks (~1kB) reported, which seem to have been fixed by the changes here. They all appear to be true positives (see comments inline). Address sanitizer is no longer reporting any issues with tutor7pp. I also ran ubsan with tutor7pp but nothing was reported.

+17 -0

0 comment

2 changed files

pr created time in 2 months

create barnchmxxo/EGSnrc

branch : sanitizers

created branch time in 2 months