On Friday, 8 September 2023 at 13:34:42 UTC, Richard (Rikki)
Andrew Cattermole wrote:
In case you didn't know, all you need to get unittests working
in -betterC is:
```d
foreach (module_; allModules) {
foreach (unitTest; __traits(getUnitTe
On Saturday, 9 September 2023 at 10:54:34 UTC, bachmeier wrote:
Hate to be that guy, but I posted a link to a stackoverflow
question with the exact error message you were getting, and the
solution. And I told you I had experienced the same error and
that question fixed it.
No reason to not sa
On Saturday, 9 September 2023 at 09:30:10 UTC, rempas wrote:
Bingo! You and Brad found out!
Hate to be that guy, but I posted a link to a stackoverflow
question with the exact error message you were getting, and the
solution. And I told you I had experienced the same error and
that question
On Saturday, 9 September 2023 at 09:56:59 UTC, H. S. Teoh wrote:
libc doesn't know what you intended. All it knows is that you
asked it for 20 bytes (even though you actually needed 40),
then later on its internal structures are corrupted (because
you thought you got 40 bytes; storing data past
On Saturday, 9 September 2023 at 09:47:14 UTC, Steven
Schveighoffer wrote:
You are focusing on the wrong problem.
You asked for size bytes, and malloc gave you size bytes. It
doesn't "know" anything special.
Then you proceeded at some point to write *past* the size
bytes. What did you overwr
On Sat, Sep 09, 2023 at 09:21:32AM +, rempas via Digitalmars-d-learn wrote:
> On Saturday, 9 September 2023 at 08:54:14 UTC, Brad Roberts wrote:
> > I'm pretty sure this is your problem. You're allocating size bytes
> > which is only going to work where sizeof(T) == 1. Changing to
> > malloc(
On Saturday, 9 September 2023 at 09:21:32 UTC, rempas wrote:
Now, if only one could expect how and why "libc" knows that and
doesn't just care to give me the memory I asked it for? Or it
could be than D does something additional without telling us?
Which can explain when this memory is only pr
On Saturday, 9 September 2023 at 09:04:18 UTC, Steven
Schveighoffer wrote:
This is not ideal. Why? Because 99% of the time, a poster has
come here with a problem they don't know how to solve, and have
focused in on where they *think* the problem is. However, the
problem isn't there. But us read
On Saturday, 9 September 2023 at 08:54:14 UTC, Brad Roberts wrote:
I'm pretty sure this is your problem. You're allocating size
bytes which is only going to work where sizeof(T) == 1.
Changing to malloc(size * sizeof(T)) is likely going to work
better.
Oh man That was it! I had forget a
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
...
That's some minimal code that I do have just to showcase it.
This is not ideal. Why? Because 99% of the time, a poster has
come here with a problem they don't know how to solve, and have
focused
On 9/8/2023 12:59 AM, rempas via Digitalmars-d-learn wrote:
u64 _cap = 0; // Total amount of elements (not bytes) we can
this._ptr = cast(T*)malloc(size);
I'm pretty sure this is your problem. You're allocating size bytes
which is only going to work where sizeof(T) == 1. Changing to
ma
On Friday, 8 September 2023 at 19:48:33 UTC, Basile B. wrote:
My idea was that if you dont have defined a copy constructor
and if an instance is assigned to another, then that other
instance share the same pointer, which can cause memory errors.
To eliminate that risk and to detect where def
On Friday, 8 September 2023 at 19:14:47 UTC, H. S. Teoh wrote:
The error message looks to me like a corruption of the malloc
heap. These kinds of bugs are very hard to trace, because they
may go undetected and only show up in specific circumstances,
so small perturbations of completely unrelate
On Friday, 8 September 2023 at 19:14:47 UTC, H. S. Teoh wrote:
My guess is that you have a double-free somewhere, or there's a
buffer overrun. Or maybe some bad interaction with the GC, e.g.
if you tried to free a pointer from the GC heap. (Note that
this may not immediately show up; free() c
On Friday, 8 September 2023 at 16:17:15 UTC, Richard (Rikki)
Andrew Cattermole wrote:
I would strongly suggest that you log all memory sizes that are
allocated, and double check that you do free.
Also turn on ASAN in ldc.
http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.
On Friday, 8 September 2023 at 19:14:47 UTC, H. S. Teoh wrote:
[...]
My guess is that you have a double-free somewhere, or there's a
buffer overrun. Or maybe some bad interaction with the GC, e.g.
if you tried to free a pointer from the GC heap.
That cant be a GC problem as rempas project is
On Friday, 8 September 2023 at 18:59:21 UTC, rempas wrote:
On Friday, 8 September 2023 at 16:02:36 UTC, Basile B. wrote:
Could this be a problem of copy construction ?
I don't think so.
My idea was that if you dont have defined a copy constructor and
if an instance is assigned to another,
On Fri, Sep 08, 2023 at 06:59:21PM +, rempas via Digitalmars-d-learn wrote:
> On Friday, 8 September 2023 at 16:02:36 UTC, Basile B. wrote:
> >
> > Could this be a problem of copy construction ?
>
> I don't think so. The assertion seems to be violated when `malloc` is used.
> And when I asser
On Friday, 8 September 2023 at 16:02:36 UTC, Basile B. wrote:
Could this be a problem of copy construction ?
I don't think so. The assertion seems to be violated when
`malloc` is used. And when I assert the result in the `_ptr`
field. Really weird...
On 08/09/2023 7:59 PM, rempas wrote:
|Fatal glibc error: malloc.c:2594 (sysmalloc): assertion failed:
(old_top == initial_top (av) && old_size == 0) || ((unsigned long)
(old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
old_end & (pagesize - 1)) == 0)|
I would strongly suggest
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
[...]
Is there any possible that there is a compiler bug? I do use
ldc2 and `betterC`!
Could this be a problem of copy construction ?
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
[I do have ... I do use ldc2 and `betterC`!]
For anyone who is still following, first of all thanks! Second, I
have bad news and good news!
The bad news is that I tested in an Linux Mint system (mine is an
Arch Linux) and the it sti
On Friday, 8 September 2023 at 14:40:13 UTC, Richard (Rikki)
Andrew Cattermole wrote:
No, for this you need ModuleInfo. The order is sequential on
what it sees first.
Personally I test using full D rather than -betterC.
For dub:
```json
"configurations": [
{
"name": "l
On Friday, 8 September 2023 at 14:50:17 UTC, Kagamin wrote:
Did you run this example program above? Does it crash?
I didn't as I suppose that it would had no problems as it works
for you. Either that, or it will be indeed a problem with my
Glibc.
I did run it now after your reply and it wo
On Friday, 8 September 2023 at 13:32:00 UTC, rempas wrote:
On Friday, 8 September 2023 at 13:05:47 UTC, evilrat wrote:
```d
import core.stdc.stdlib;
import core.stdc.stdio;
alias u64 = ulong;
alias i64 = long;
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0
On 09/09/2023 2:20 AM, rempas wrote:
Do they have automatic symbol order resolution? Which is, testing
symbols that other symbol depend on first? Or is it random?
No, for this you need ModuleInfo. The order is sequential on what it
sees first.
Personally I test using full D rather than -bett
On Friday, 8 September 2023 at 13:34:42 UTC, Richard (Rikki)
Andrew Cattermole wrote:
In case you didn't know, all you need to get unittests working
in -betterC is:
```d
foreach (module_; allModules) {
foreach (unitTest; __traits(getUnitTe
In case you didn't know, all you need to get unittests working in
-betterC is:
```d
foreach (module_; allModules) {
foreach (unitTest; __traits(getUnitTests,
module_)) {
unitTest();
On Friday, 8 September 2023 at 13:05:47 UTC, evilrat wrote:
You run with -unittest compiler flag? Well, that does nothing
for me with betterc (without it is ok).
I did stupid and unsafe things like malloc(0) and writing out
of bounds but still no crash, it works fine.
I guess it depends on
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we
can store
public:
/* Create a vector by just allocating memory f
On Friday, 8 September 2023 at 11:50:52 UTC, rempas wrote:
That's interesting, I wasn't able to find something else! The
bug happens when I run the testing suit and well... the tests
before pass so I cannot find anything that goes wrong except
for the fact that I do not free the memory that i
On Friday, 8 September 2023 at 09:25:59 UTC, Hipreme wrote:
Hello, not completely unrelated to your problem, I have also
done something like that, and when you're in D, don't use
simply a pointer and length like that, use the `slice` operator.
See references:
https://tour.dlang.org/tour/en/
On Friday, 8 September 2023 at 09:07:12 UTC, evilrat wrote:
Hard to tell from that code but it is quite unlikely there is a
compiler bug in such simple use case.
I assume you already tried debugging your program, right?
Yep! I have spent days and it's these kinds of bugs that burn me
off a
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we
can store
public:
/* Create a vector by just allocating memory f
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we
can store
public:
/* Create a vector by just allocating memory f
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we can
store
public:
/* Create a vector by just allocating memory for it. The null
terminator is not set for
strings as,
36 matches
Mail list logo
