September 09, 2023
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 -betterC.

For dub:

```json
    "configurations": [
        {
            "name": "library",
            "targetType": "dynamicLibrary",
            "versions": [
                "DynamicSideroBase"
            ],
            "buildOptions": [
                "betterC"
            ]
        },
        {
            "name": "static",
            "targetType": "staticLibrary",
            "buildOptions": [
                "betterC"
            ]
        },
        {
            "name": "unittest"
        },
        {
            "name": "executable",
            "targetType": "executable"
        }
    ]
```
September 08, 2023

On Friday, 8 September 2023 at 13:32:00 UTC, rempas wrote:

>

On Friday, 8 September 2023 at 13:05:47 UTC, evilrat wrote:

>
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;   // Total amount of elements (not bytes) we can store
  u64 _len = 0;

public:
  /* Create a vector by just allocating memory for it. The null terminator is not set for
     strings as, the vector is considered empty and we should  first push something to it
     in order to use it! */
  this(i64 size) {
    this._len = 0;
    this._cap = size;

    static if (is(T == char)) { size += 1; } // Additional space for the null terminator
    this._ptr = cast(T*)malloc(size);
  }

  ref T opIndex(size_t idx) { return _ptr[idx]; }
}

extern(C)
void main()
//unittest
{
    enum el = 3;
    auto vec = Vec!char(10);
    assert(vec._ptr);
    vec[el] = 'h';
    assert(vec[el] == 'h');
    printf("ptr = %p\n", vec._ptr);
    printf("vec ptr = %p\n", &vec[el]);
    printf("vec local = %p\n", &vec);
    printf("vec[%d] = %c\n", el, vec[el]);
    foreach (i; 0..vec._cap) {
      printf("-");
    }
    printf("\n");
    foreach (i; 0..vec._cap) {
      printf("%d", vec[i]);
    }
    printf("\n");
    printf("run ok\n");
}

ldc2 -betterC -run membug.d

output

ptr = 0x55cb701de2a0
vec ptr = 0x55cb701de2a3
vec local = 0x7fffa1542258
vec[3] = h
----------
000104000000
run ok

I have made a search on the web and I found out one thread that pointed out that it may be a Glibc error. However, because like I said the problem only happens when I assign the returned value to the _ptr field, I just wanted to post here in case someone has a similar experience and if it's a compiler bug in which case, we should report it.

Did you run this example program above? Does it crash?

September 08, 2023

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 works without any problems!

September 08, 2023
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": "library",
>             "targetType": "dynamicLibrary",
>             "versions": [
>                 "DynamicSideroBase"
>             ],
>             "buildOptions": [
>                 "betterC"
>             ]
>         },
>         {
>             "name": "static",
>             "targetType": "staticLibrary",
>             "buildOptions": [
>                 "betterC"
>             ]
>         },
>         {
>             "name": "unittest"
>         },
>         {
>             "name": "executable",
>             "targetType": "executable"
>         }
>     ]
> ```

Thank you for all the information! I really appreciate it my friend!
September 08, 2023

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 still doesn't work. So unless it's a bug in EVERY glibc on Linux, it will take me days to find it at best (I can feel the burnout coming!)...

The good news is that I have uploaded the source code and as I have already asked for help for that codebase in the past and I'll probably ask in the future, I now have a proper codebase to showcase when the "smallest possible example" is not enough!

More specifically, look at the showcases Vec struct and the template that it expands on its body!

The test that fails is for a function called split and it is located here (I specifically point to the line that fails inside the test).

Once again, thank you all for the support!

September 08, 2023

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 ?

September 09, 2023
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 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.html
September 08, 2023

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...

September 08, 2023
On Fri, Sep 08, 2023 at 06:59:21PM +0000, 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 assert the result in the `_ptr` field. Really weird...

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 unrelated code may make the bug appear or disappear -- just because the bug doesn't show up when you disable some code does not prove that that's where the problem is; it could be that corruption is still happening, it just so happens that it goes unnoticed when the behaviour of the code changes slightly.

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() could've assumed that everything was OK when it has in fact messed up its internal data structures; the problem would only show up later on in code that's actually unrelated to the real problem.)

If I were in your shoes I'd use Valgrind / Memcheck to try to find the real cause of the problem.  Chances are, it may have nothing to do with the bit of code you quoted at all.  You could try to insert extra malloc/free's in various places around the code (in places along the code path, but unrelated to the problematic code) to see if that changes the behaviour of the bug. If it does, your corruption is likely somewhere other than the _ptr code you showed.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
September 08, 2023

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, then that other instance share the same pointer, which can cause memory errors.

To eliminate that risk and to detect where default post-blitting may happen you can add

@disable this(this);

to the struct.