July 23, 2021

On 7/22/21 7:43 PM, apz28 wrote:

>

FbConnection is a class, FbXdrReader is a struct and for this call, response.data is not null & its' length will be greater than zero and FbConnection is not being used. So why DMD try to evaluate at compiled time hence error

  1. Should not evaluate at compile time for this function call/construct
  2. The error message is missing proper line # or nothing related to the module displayed in error message

https://github.com/apz28/dlang/blob/main/source/pham/db/db_fbbuffer.d#L527

I have a feeling that line is backwards.

It says: if the buffer has length, ignore it and use the connection, otherwise use the (empty) buffer data.

So perhaps this is actually a real error that is being flagged (because it's inlined)?

In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called.

-Steve

July 23, 2021

On Friday, 23 July 2021 at 18:44:47 UTC, Steven Schveighoffer wrote:

>

On 7/22/21 7:43 PM, apz28 wrote:

>

In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called.

-Steve

The -debug build with passing unit-tests so no problem there.
The -release build is having problem. After make change to accommodate it, it takes forever to build. I started it yesterday 11AM and it is still compiling now (more than a day already.) It takes a full 100% core and peek memory usage is 2.2GB. The hard-drive is SSD

July 23, 2021
On 7/23/21 12:30 PM, apz28 wrote:

> The -debug build with passing unit-tests so no problem there.
> The -release build is having problem. After make change to accommodate
> it, it takes forever to build. I started it yesterday 11AM and it is
> still compiling now (more than a day already.) It takes a full 100% core
> and peek memory usage is 2.2GB. The hard-drive is SSD

There is definitely something wrong with the compiler. That build time is ridiculously high.

Ali

July 23, 2021

On 7/23/21 3:30 PM, apz28 wrote:

>

On Friday, 23 July 2021 at 18:44:47 UTC, Steven Schveighoffer wrote:

>

On 7/22/21 7:43 PM, apz28 wrote:

>

In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called.

The -debug build with passing unit-tests so no problem there.
The -release build is having problem. After make change to accommodate it, it takes forever to build. I started it yesterday 11AM and it is still compiling now (more than a day already.) It takes a full 100% core and peek memory usage is 2.2GB. The hard-drive is SSD

That is a separate problem. That build is hung, and you likely have found a bug in the compiler. I have never seen a build last more than a few minutes at the most.

If the code you posted is not crashing with a segfault, then it's possible there is a code generation issue. I still believe you have your check backwards.

-Steve

1 2
Next ›   Last »