Re: Bug on dmd or gdc ?
Domingo Alvarez Duarte:
Based on a question about manually allocated structures with
payload I found that a solution proposed seems to work when
compiled with dmd but segfaults when compiled with gdc.
...
int size;
char[0] _b;
@property char[] buf() { return (_b.ptr)[0..size];}
}
I guess you are using different versions of the front-end.
Zero-length arrays was null before, and it's not null in V. 2.066.
So probably there is no bug, just a little design change for the
better.
Bye,
bearophile
Tracing down core.exception.InvalidMemoryOperationError
Hi, at the end of my program it throws InvalidMemoryOperationError. Looking at the documentation and past forum questions I learned that it is probably because of allocations in destructors. However, I have no such thing in my code (at least not intentionally). I am suspecting the std.logger package, because it throwed on me a memory error on occasions. But regardless of the source, I would like to trace it and deal with it. But I do not have much of an idea where to start. Could you give me an advice? Thanks, Drasha
Re: Bug on dmd or gdc ?
On Monday, 28 July 2014 at 08:16:37 UTC, bearophile wrote:
Domingo Alvarez Duarte:
Based on a question about manually allocated structures with
payload I found that a solution proposed seems to work when
compiled with dmd but segfaults when compiled with gdc.
...
int size;
char[0] _b;
@property char[] buf() { return (_b.ptr)[0..size];}
}
I guess you are using different versions of the front-end.
Zero-length arrays was null before, and it's not null in V.
2.066.
So probably there is no bug, just a little design change for
the better.
Bye,
bearophile
Thanks ! You are right I'm using dmd 2.066 and gdc 4.8/4.9,
Cheers !
Re: Tracing down core.exception.InvalidMemoryOperationError
On Monday, 28 July 2014 at 09:38:35 UTC, Martin Drasar via Digitalmars-d-learn wrote: Hi, at the end of my program it throws InvalidMemoryOperationError. Looking at the documentation and past forum questions I learned that it is probably because of allocations in destructors. However, I have no such thing in my code (at least not intentionally). I am suspecting the std.logger package, because it throwed on me a memory error on occasions. But regardless of the source, I would like to trace it and deal with it. But I do not have much of an idea where to start. Could you give me an advice? More broadly speaking, it is thrown whenever certain memory operations are attempted while the GC is running, 6 in all, as you can see here: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458 I believe I stuck in printfs till I found out which one was run before the error was thrown, and then traced that back with more printfs to where it was getting called. I didn't have a debugger available, you may be able to trace faster with one.
Re: Tracing down core.exception.InvalidMemoryOperationError
On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote: > More broadly speaking, it is thrown whenever certain memory operations > are attempted while the GC is running, 6 in all, as you can see here: > > https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458 > > > I believe I stuck in printfs till I found out which one was run before > the error was thrown, and then traced that back with more printfs to > where it was getting called. I didn't have a debugger available, you > may be able to trace faster with one. Hi, thanks for the tip. I have a debugger at hand and I am would prefer to use it. However, I don't really know where and how to start. I would like to break at core/exception.d when onInvalidMemoryOperationError is called, but I am not sure how to build druntime with debug information. There does not seem to be some flag in the makefile like for dmd. Is there some document describing how to do this? Thanks, Drasha
D may disappoint in the presence of an alien Garbage Collector?
Suppose I want to use D as a system programming language to work with a library of functions written in another language, operating on dynamically typed data that has its own garbage collector, such as an algebra system or the virtual machine of a dynamically typed scripting language viewed as a library of operations on its own data type. For concreteness, suppose the library is written in C. (More generally, the data need not restricted to the kind above, but for concreteness, make that supposition.) Data in such a system is usually a (possibly elaborate) tagged union, that is essentially a struct consisting of (say) two words, the first indicating the type and perhaps containing some bits that indicate other attributes, and the second containing the data, which may be held directly or indirectly. Call this a Descriptor. Descriptors are small, so it's natural to want them held by value and not allocated on the heap (either D's or the library's) unless they are a part of a bigger structure that naturally resides there. And it's natural to want them to behave like values when passed as parameters or assigned. This usually fits in with the sort of heterogeneous copy semantics of such a library, where some of the dynamic types are implicitly reference types and others are not. The trouble is that the library's alien GC needs to be made aware of each Descriptor when it appears and when it disappears, so that a call of a library function that allocates storage doesn't trigger a garbage collection that vacuums up library allocated storage that a D Descriptor points to, or fails to adjust a pointer inside a D descriptor when it moves the corresponding data, or worse, follows a garbage pointer from an invalid D Descriptor that's gone out of scope. This requirement applies to local variables, parameters and temporaries, as well as to other situations, like D arrays of Descriptors that are D-heap allocated. Ignore the latter kind of occasion for now. Abstract the process of informing the GC of a Descriptor's existence as a Protect operation, and that it will be out of scope as an Unprotect operation. Protect and Unprotect naturally need the address of the storage holding the relevant Descriptor. In a nutshell, the natural requirement when interfacing to such a library is to add Descriptor as a new value type in D along the lines described above, with a definition such that Protect and Unprotect operations are compiled to be performed automatically at the appropriate junctures so that the user of the library can forget about garbage collection to the usual extent. How can this requirement be fulfilled?
Re: D may disappoint in the presence of an alien Garbage Collector?
On Monday, 28 July 2014 at 19:57:38 UTC, Carl Sturtivant wrote: Suppose I want to use D as a system programming language to work with a library of functions written in another language, operating on dynamically typed data that has its own garbage collector, such as an algebra system or the virtual machine of a dynamically typed scripting language viewed as a library of operations on its own data type. For concreteness, suppose the library is written in C. (More generally, the data need not restricted to the kind above, but for concreteness, make that supposition.) Data in such a system is usually a (possibly elaborate) tagged union, that is essentially a struct consisting of (say) two words, the first indicating the type and perhaps containing some bits that indicate other attributes, and the second containing the data, which may be held directly or indirectly. Call this a Descriptor. Descriptors are small, so it's natural to want them held by value and not allocated on the heap (either D's or the library's) unless they are a part of a bigger structure that naturally resides there. And it's natural to want them to behave like values when passed as parameters or assigned. This usually fits in with the sort of heterogeneous copy semantics of such a library, where some of the dynamic types are implicitly reference types and others are not. The trouble is that the library's alien GC needs to be made aware of each Descriptor when it appears and when it disappears, so that a call of a library function that allocates storage doesn't trigger a garbage collection that vacuums up library allocated storage that a D Descriptor points to, or fails to adjust a pointer inside a D descriptor when it moves the corresponding data, or worse, follows a garbage pointer from an invalid D Descriptor that's gone out of scope. This requirement applies to local variables, parameters and temporaries, as well as to other situations, like D arrays of Descriptors that are D-heap allocated. Ignore the latter kind of occasion for now. Abstract the process of informing the GC of a Descriptor's existence as a Protect operation, and that it will be out of scope as an Unprotect operation. Protect and Unprotect naturally need the address of the storage holding the relevant Descriptor. In a nutshell, the natural requirement when interfacing to such a library is to add Descriptor as a new value type in D along the lines described above, with a definition such that Protect and Unprotect operations are compiled to be performed automatically at the appropriate junctures so that the user of the library can forget about garbage collection to the usual extent. How can this requirement be fulfilled? Suppose I want to do system programming...Would I choose the option with a GC ? Just get off. The GC is just such a fagot. People are smart enough to manage memory.
Re: D may disappoint in the presence of an alien Garbage Collector?
On Monday, 28 July 2014 at 19:57:38 UTC, Carl Sturtivant wrote:
Suppose I want to use D as a system programming language to
work with a library of functions written in another language,
operating on dynamically typed data that has its own garbage
collector, such as an algebra system or the virtual machine of
a dynamically typed scripting language viewed as a library of
operations on its own data type. For concreteness, suppose the
library is written in C. (More generally, the data need not
restricted to the kind above, but for concreteness, make that
supposition.)
Data in such a system is usually a (possibly elaborate) tagged
union, that is essentially a struct consisting of (say) two
words, the first indicating the type and perhaps containing
some bits that indicate other attributes, and the second
containing the data, which may be held directly or indirectly.
Call this a Descriptor.
Descriptors are small, so it's natural to want them held by
value and not allocated on the heap (either D's or the
library's) unless they are a part of a bigger structure that
naturally resides there. And it's natural to want them to
behave like values when passed as parameters or assigned. This
usually fits in with the sort of heterogeneous copy semantics
of such a library, where some of the dynamic types are
implicitly reference types and others are not.
The trouble is that the library's alien GC needs to be made
aware of each Descriptor when it appears and when it
disappears, so that a call of a library function that allocates
storage doesn't trigger a garbage collection that vacuums up
library allocated storage that a D Descriptor points to, or
fails to adjust a pointer inside a D descriptor when it moves
the corresponding data, or worse, follows a garbage pointer
from an invalid D Descriptor that's gone out of scope. This
requirement applies to local variables, parameters and
temporaries, as well as to other situations, like D arrays of
Descriptors that are D-heap allocated. Ignore the latter kind
of occasion for now.
Abstract the process of informing the GC of a Descriptor's
existence as a Protect operation, and that it will be out of
scope as an Unprotect operation. Protect and Unprotect
naturally need the address of the storage holding the relevant
Descriptor.
In a nutshell, the natural requirement when interfacing to such
a library is to add Descriptor as a new value type in D along
the lines described above, with a definition such that Protect
and Unprotect operations are compiled to be performed
automatically at the appropriate junctures so that the user of
the library can forget about garbage collection to the usual
extent.
How can this requirement be fulfilled?
If I understand you correctly, an easy way is to use RefCounted
with a simple wrapper. Something like this:
// Descriptor defined by the external library
struct DescriptorImpl
{
size_t type;
void* data;
}
// Tiny wrapper telling the alien GC of the existence of this
reference
private struct DescriptorWrapper
{
DescriptorImpl descriptor;
alias descriptor this;
@disable this();
this(DescriptorImpl desc)
{
// Make alien GC aware of this reference
}
~this()
{
// Make alien GC aware this reference is no longer valid
}
}
// This is the type you will be working with on the D side
alias Descriptor = RefCounted!DescriptorWrapper;
Re: Tracing down core.exception.InvalidMemoryOperationError
On Monday, 28 July 2014 at 13:31:08 UTC, Martin Drasar via Digitalmars-d-learn wrote: On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote: More broadly speaking, it is thrown whenever certain memory operations are attempted while the GC is running, 6 in all, as you can see here: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458 I believe I stuck in printfs till I found out which one was run before the error was thrown, and then traced that back with more printfs to where it was getting called. I didn't have a debugger available, you may be able to trace faster with one. Hi, thanks for the tip. I have a debugger at hand and I am would prefer to use it. However, I don't really know where and how to start. I would like to break at core/exception.d when onInvalidMemoryOperationError is called, but I am not sure how to build druntime with debug information. There does not seem to be some flag in the makefile like for dmd. Is there some document describing how to do this? It's not in the makefile; I simply added the -g or -gc flag where it compiled and then the debug symbols showed up in the debugger. You may also want to experiment with the -debug flag, which will turn on various kinds of log output depending on which module and flag you use it with.
Re: Tracing down core.exception.InvalidMemoryOperationError
On Monday, 28 July 2014 at 22:13:56 UTC, Joakim wrote: On Monday, 28 July 2014 at 13:31:08 UTC, Martin Drasar via Digitalmars-d-learn wrote: On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote: More broadly speaking, it is thrown whenever certain memory operations are attempted while the GC is running, 6 in all, as you can see here: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458 I believe I stuck in printfs till I found out which one was run before the error was thrown, and then traced that back with more printfs to where it was getting called. I didn't have a debugger available, you may be able to trace faster with one. Hi, thanks for the tip. I have a debugger at hand and I am would prefer to use it. However, I don't really know where and how to start. I would like to break at core/exception.d when onInvalidMemoryOperationError is called, but I am not sure how to build druntime with debug information. There does not seem to be some flag in the makefile like for dmd. Is there some document describing how to do this? It's not in the makefile; I simply added the -g or -gc flag where it compiled and then the debug symbols showed up in the debugger. You may also want to experiment with the -debug flag, which will turn on various kinds of log output depending on which module and flag you use it with. I can tell you it is the logger, for sure. I have had similar problems in the past because I was trying to print a string in a destructor, and even just using the string concatenation is enough for an allocation to happen and for the exception to ruin everything. As a bonus, the exception is thrown from another thread :P In fact, now that we have @nogc I really think we could use *at least a warning* if the compiler determines that allocation might happen inside a destructor... (btw: a debug strategy might be: fire up dmd beta 2.066, add @nogc at all destructors and see where the compiler complains)
Re: Showing a user specified error message when no overloads match
opDispatch behaves as though it has SFINAE. When something fails in the definition (like I am having now, some of the symbols I used in it hadn't been imported) there won't ever be an error message, I just get "Error: no property 'bar' for type 'Foo'" In one case I had to use static ifs and pragmas and static assert(0) to get error messages out of opDispatch because static assert messages were being suppressed. Its very frustrating.
