On 12/09/2014 08:53 AM, Steven Schveighoffer wrote:
On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
that file can be already finalized. please remember that `~this()` is
more a finalizer than destructor, and it's called on *dead* object.
Agreed: D has a terminology issue here,
On 3/25/15 9:51 AM, Ali Çehreli wrote:
On 12/09/2014 08:53 AM, Steven Schveighoffer wrote:
On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
that file can be already finalized. please remember that `~this()` is
more a finalizer than destructor, and it's called on *dead* object.
On 12/12/14 10:50 AM, Steven Schveighoffer wrote:
On 12/12/14 7:52 AM, Ruslan Mullakhmetov wrote:
btw, i used suggested trackallocs.d and GC defenetely receives NO_SCAN
before tag: 1 len: 2 ptr: 103A78058 root: 103A77000:8192 attr: APPENDABLE
gc_qalloc(41, NO_SCAN APPENDABLE ) cc: 29106 asz:
On Thursday, 11 December 2014 at 18:36:59 UTC, Steven
Schveighoffer wrote:
My analysis so far:
2. In the array append code, the block attributes are obtained
via GC.query, which has this code for getting the attributes:
On Friday, 12 December 2014 at 12:53:00 UTC, Ruslan Mullakhmetov
wrote:
On Thursday, 11 December 2014 at 18:36:59 UTC, Steven
Schveighoffer wrote:
My analysis so far:
4. If your code is multi-threaded, but using __gshared, it can
make the cache incorrect. Are you doing this?
the app is
On 12/12/14 7:52 AM, Ruslan Mullakhmetov wrote:
On Thursday, 11 December 2014 at 18:36:59 UTC, Steven Schveighoffer wrote:
My analysis so far:
2. In the array append code, the block attributes are obtained via
GC.query, which has this code for getting the attributes:
On Friday, 12 December 2014 at 15:50:26 UTC, Steven Schveighoffer
wrote:
Can I email you at this address? If not, email me at the
address from my post to let me know your contact, no reason to
work through building issues on the public forum :)
-Steve
reach me at theambient [] me__com
On 12/10/14 7:52 AM, Ruslan Mullakhmetov wrote:
On Wednesday, 10 December 2014 at 08:46:12 UTC, Ruslan Mullakhmetov wrote:
yes. that was the mistake. also after fixing bug in Blk Attributes
printing i got more reasonable attrs
for object blk: FINALIZE
for array of objects blk: NO_SCAN
On 12/10/14 7:52 AM, Ruslan Mullakhmetov wrote:
On Wednesday, 10 December 2014 at 08:46:12 UTC, Ruslan Mullakhmetov wrote:
yes. that was the mistake. also after fixing bug in Blk Attributes
printing i got more reasonable attrs
for object blk: FINALIZE
for array of objects blk: NO_SCAN
On Wednesday, 10 December 2014 at 02:43:19 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 17:18:44 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
but i still have no clue how to overcome GC =(
why do you want to fight with GC? most of
On Wed, 10 Dec 2014 08:32:12 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 10 December 2014 at 02:43:19 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 17:18:44 +
Ruslan Mullakhmetov via Digitalmars-d-learn
On Tuesday, 9 December 2014 at 21:38:57 UTC, Steven Schveighoffer
wrote:
On 12/9/14 2:56 PM, Steven Schveighoffer wrote:
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote:
array holds 11 64bit pointers but it's block size is only 128
bytes 11
* 64 = 704 bytes. what's wrong with this
On Wednesday, 10 December 2014 at 08:46:12 UTC, Ruslan
Mullakhmetov wrote:
yes. that was the mistake. also after fixing bug in Blk
Attributes printing i got more reasonable attrs
for object blk: FINALIZE
for array of objects blk: NO_SCAN APPENDABLE
this is sound good except for NO_SCAN.
...
On Wed, 10 Dec 2014 12:52:22 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 10 December 2014 at 08:46:12 UTC, Ruslan
Mullakhmetov wrote:
yes. that was the mistake. also after fixing bug in Blk
Attributes printing i got more
On Wednesday, 10 December 2014 at 12:52:24 UTC, Ruslan
Mullakhmetov wrote:
why and how this happens? can anybody explain it to me?
I tried to extract this and saw NO NO_SCAN attrs after moving blk:
the following piece of output produced by
http://dpaste.dzfl.pl/6f773e17de92
len: 6
On Wednesday, 10 December 2014 at 13:00:45 UTC, ketmar via
Digitalmars-d-learn wrote:
can you give us a minified code that causes this behavior?
see previous post. the problem vanish if i try to extract it.
On Wed, 10 Dec 2014 13:03:21 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 10 December 2014 at 12:52:24 UTC, Ruslan
Mullakhmetov wrote:
why and how this happens? can anybody explain it to me?
I tried to extract this and saw NO
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and tracing i
found this is because of accessing not allocated memory.
I did the following checks:
- added to some class invariant check for access to suspicious
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC somehow collects live objects.
I found it because i got segfaults. After debugging and tracing i found
this is because of accessing not allocated memory.
I did the following checks:
- added to some
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and
tracing i found
this is because of
On 12/9/14 9:52 AM, Ruslan Mullakhmetov wrote:
No, there is no accessing GC resources in dtors.
the only usage of dtor in one class is
~this()
{
_file.close();
}
where _file is of type std.file.File
That should work I think.
i'll try to extract problem to any
It may happen if only reference to an object is stored in memory
block marked as data-only (using ubyte[] for a buffer is probably
most common reason I have encountered)
On Tue, 09 Dec 2014 14:52:53 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC
On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 14:52:53 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov
On Tuesday, 9 December 2014 at 16:53:02 UTC, Steven Schveighoffer
wrote:
On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 14:52:53 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 9 December 2014 at 14:23:06
On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote:
It may happen if only reference to an object is stored in
memory block marked as data-only (using ubyte[] for a buffer is
probably most common reason I have encountered)
Thanks for interesting hypothesis, but that's not the issue.
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote:
On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote:
It may happen if only reference to an object is stored in memory block
marked as data-only (using ubyte[] for a buffer is probably most
common reason I have encountered)
Thanks for
On Tuesday, 9 December 2014 at 19:56:30 UTC, Steven Schveighoffer
wrote:
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote:
On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote:
i checked attributes for GC block holding this array:
FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR
That does
On 12/9/14 3:18 PM, Ali Çehreli wrote:
On 12/09/2014 11:56 AM, Steven Schveighoffer wrote:
i checked attributes for GC block holding this array:
```
FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR
```
That does not sound right at all. No block should ever have both
FINALIZE
On 12/9/14 3:24 PM, Ruslan Mullakhmetov wrote:
On Tuesday, 9 December 2014 at 19:56:30 UTC, Steven Schveighoffer wrote:
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote:
On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote:
i checked attributes for GC block holding this array:
FINALIZE
On Tue, 09 Dec 2014 17:18:44 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
thanks, I got it: either C++ or D dtors are minefield =)
and in D this is filed *made* of mines. ;-)
but i still have no clue how to overcome GC =(
why do you want to fight
31 matches
Mail list logo
