#Dlang / Dub bugs?

1 messages · Page 1 of 1 (latest)

compact pebble
#

I ran into a couple compiler/dub bugs on windows yesterday. if your dub.json has:

        "debug": {
            "debugVersions": ["Debug"],
            "dflags": ["-g"]   // redudant, and explodes the pdb file at linking stage for both DMD and LDC2, windows linker will complain about 
        },

LINK : fatal error LNK1318: Unexpected PDB error; 'LIMIT (12)'

and another issue, perhaps because dub TOML hasn't been updated in awhile, or, a compiler bug, I can't run profile=gc with DMD (LDC2 doesn't have it? and complains of invalid options)

 "dflags": [ "-profile=gc"]

It seems like its corrupting the mixins trying to insert the profiling code:

(dmd-2.112.0)novous@sparky:~/Desktop/git2/spacehole2$ dub --build=profilegc --force Starting Performing "profilegc" build using /home/novous/dlang/dmd-2.112.0/linux/bin64/dmd for x86_64. 
Building raylib-d 6.0.1: building configuration [library] 
Building toml 2.0.1: building configuration [library] 
/home/novous/dlang/dmd-2.112.0/linux/bin64/../../src/druntime/import/core/internal/array/construction.d-mixin-685(689,27): Error: undefined identifier TOMLValue string name = TOMLValue[].stringof; ^ ../../../.dub/packages/toml/2.0.1/toml/src/toml/toml.d(1059,45): Error: template instance core.internal.array.construction._d_arrayliteralTXTrace!(TOMLValue) error instantiating set([keys[$ - 1]], TOMLValue([TOMLValue(TOML_TYPE.TABLE)])); ^ ../../../.dub/packages/toml/2.0.1/toml/src/toml/toml.d(573,11): instantiated from here: parseTOMLImpl!true return parseTOMLImpl!true(data, options); ^ ../../../.dub/packages/toml/2.0.1/toml/src/toml/toml.d(577,11): Error: template instance toml.toml.parseTOMLImpl!false error instantiating return parseTOMLImpl!false(data, options); 
^ Error /home/novous/dlang/dmd-2.112.0/linux/bin64/dmd failed with exit code 1.

Versions of tools (to follow in next post)

#

Versions (Windows 11, x64 obviously)

$ dmd --version
DMD64 D Compiler v2.108.1
Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved written by Walter Bright

$ LDC2 --version
LDC - the LLVM D compiler (1.38.0):
  based on DMD v2.108.1 and LLVM 18.1.5
  built with LDC - the LLVM D compiler (1.38.0)
  Default target: x86_64-pc-windows-msvc
  Host CPU: znver3
  http://dlang.org - http://wiki.dlang.org/LDC

$ dub --version
DUB version 1.37.0, built on May 11 2024
#

chatGPT was like "nobody uses profile-gc anymore because it's ancient/outdated". Not sure if true or not.

wooden tide
#

If this option is available for your case

spice mulch
#

-g is passed automatically by dub in debug builds. It will also print some warnings if you put it in your dub file. About the toml package, you are right that there is a weird issue there. I am getting it too on Linux when I use that flag. Not sure why yet.

spice mulch
#

This might be a DMD + -profile=gc bug.

  • OpenD's DMD64 OpenD Compiler v2.107.0-beta.1 works fine
  • DMD v2.112.0 fails with same template errors
  • DMD v2.113.0-beta.1 fails with a error message: ERROR: This is a compiler bug.
    The output of the last one is in the file.
📎 output.txt
smoky gale
smoky gale
wooden tide
#

Yes — using D’s -profile=gc flag can make a lot of sense, but mostly as a diagnostic/profiling tool rather than something you keep enabled regularly.
The flag instruments GC allocations and writes a profilegc.log file at program exit. It reports where GC allocations happened, how many, and how many bytes were allocated.
Example:
dmd -profile=gc app.d
./app
Then inspect:
profilegc.log
Typical output:
bytes allocated, allocations, type, function, file:line
When it’s useful
It’s especially valuable if you want to:
reduce GC pressure
optimize latency-sensitive code
enforce <@&488729996341542933> boundaries
investigate unexpected allocations
tune game loops / realtime sections
see whether Phobos calls allocate
This is often the first practical step before attempting more aggressive approaches like <@&488729996341542933> or -betterC.
Important caveats
The profiling is not perfect or complete.
The compiler docs explicitly note that only instrumented allocations are logged. These include:
language-level allocations
many Phobos allocations
allocations through core.memory.GC
But allocations performed through other APIs or lower-level GC internals may not appear.
So:
absence from the log does not guarantee “no allocation”
some reallocations or runtime behaviors can look surprising
optimizer effects may change what appears
Performance overhead
You generally should not benchmark runtime performance with -profile=gc enabled because:
instrumentation adds overhead
allocation patterns can shift slightly
timings become less representative
Use it for:
discovery
hotspot analysis
regression checks
Then disable it for actual performance measurements.

wooden tide