February 13, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg |
On 2/13/2012 11:32 PM, Jacob Carlborg wrote:
> On 13 Feb, 2012,at 11:37 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
>
>> What exact version of dmd/druntime/phobos are you using?
>> Is this related to the GC locking changes?
> These changes:
>
> https://github.com/D-Programming-Language/druntime/commit/f4d798b0138030b80c8d898e237948046e191c0d
>
> Do not appear to be present in the latest beta, at least not in the druntime sources that are bundled.
>
So are you saying the problem you're having occurs with the beta, or with the latest version you got from github?
|
February 14, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 14 Feb, 2012,at 08:58 AM, Walter Bright <walter at digitalmars.com> wrote: > > > On 2/13/2012 11:32 PM, Jacob Carlborg wrote: > > On 13 Feb, 2012,at 11:37 PM, Martin Nowak <dawg at dawgfoto.de> wrote: > > > >> What exact version of dmd/druntime/phobos are you using? > >> Is this related to the GC locking changes? > > These changes: > > > > https://github.com/D-Programming-Language/druntime/commit/f4d798b0138030b80c8d898e237948046e191c0d > > > > Do not appear to be present in the latest beta, at least not in the druntime sources that are bundled. > > With the beta. -- /Jacob Carlborg? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120214/0d6260c5/attachment-0001.html> |
February 15, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | > I'm seeing some general problem with array appending. Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending.
>
Any futher insights on this?
Even a bigger test case would be helpful if it reproduces the error.
|
February 14, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 02/13/2012 12:23 PM, Walter Bright wrote:
>
>
> On 2/13/2012 3:05 AM, Daniel Murphy wrote:
>> Please take a look at the message I left on https://github.com/D-Programming-Language/dmd/commit/f330b950171adb67d2b648885c528b2fd5909130#comments
>>
>>
>> I think it's a regression.
>>
>
> I have a hard time mentally connecting which name is used on the mailing list with which pseudonym on github. I know if I click on yebblies I get Daniel Murphy, but it would be more convenient if you used DanielMurphy as the github handle. This applies to everyone.
>
> And btw, using your own name for the commits will increase your professional ranking in Google searches, as Google will be able to find your contributions easily :-).
As far as most of the people who I interact with online go, if I started using my legal name they mostly wouldn't know who I am.
Consistency is king.
|
February 15, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 15 Feb, 2012,at 01:35 AM, Martin Nowak <dawg at dawgfoto.de> wrote: > > I'm seeing some general problem with array appending. Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending. > > > > Any futher insights on this? > Even a bigger test case would be helpful if it reproduces the error. Unfortunately no. I have a big test case: This example: http://pastebin.com/k1QQnhEp together with Orange: https://github.com/jacob-carlborg/orange Just place the example in the same folder as Orange and run it with RDMD.? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120215/6473f447/attachment-0001.html> |
February 15, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Wed, 15 Feb 2012 08:52:52 +0100, Jacob Carlborg <doob at me.com> wrote: > On 15 Feb, 2012,at 01:35 AM, Martin Nowak <dawg at dawgfoto.de> wrote: > >> > I'm seeing some general problem with array appending. Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending. >> > >> >> Any futher insights on this? >> Even a bigger test case would be helpful if it reproduces the error. > Unfortunately no. I have a big test case: > > This example: http://pastebin.com/k1QQnhEp > together with Orange: https://github.com/jacob-carlborg/orange > > Just place the example in the same folder as Orange and run it with RDMD.? I get an infinite recursion. Starting from Serializer.d(1107): return deserializeObject!(T)(keyOrId); // with keyOrId being "refme" the recursive field name in Foo #29 0x000000000040a947 in orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal() (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at orange/serialization/Serializer.d:1104 #30 0x000000000040ad53 in orange.serialization.Serializer.Serializer.__T29objectStructDeserializeHelperTC4main3FooZ.objectStructDeserializeHelper() (this=0x8006c4a00, value=<error reading variable>) at orange/serialization/Serializer.d:1482 #31 0x000000000040ac7e in orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject() (this=0x80128b1c0) at orange/serialization/Serializer.d:1181 #32 0x000000000040a89f in orange.serialization.Serializer.Serializer.__T13triggerEventsTC4main3FooZ.triggerEvents() (this=0x8006c4a00, dg=0x000000000040aa94000000080128b1c0, value=0x80128c860) at orange/serialization/Serializer.d:1749 #33 0x000000000040aa8b in orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject() (this=0x80128b1c0) at orange/serialization/Serializer.d:1153 #34 0x00000000004061cb in orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject() (this=0x80128b140) at orange/serialization/archives/XmlArchive.d:1366 #35 0x0000000000417cdb in orange.util.Use.__T7restoreTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.restore() (this=0x0, value=0x8006c6f50, dg=0x000000000040603c000000080128b140) at orange/util/Use.d:162 #36 0x0000000000417b94 in orange.util.Use.__T13RestoreStructTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.RestoreStruct.opIn() (this=0x7fffffbffc20, deleg=0x000000000040603c000000080128b140) at orange/util/Use.d:127 #37 0x0000000000406035 in orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject() (this=0x8006c6f00, dg=..., result=0x80128b1c8, id=0x7fffffbffc98, key=0x0000000000459eb00000000000000005) at orange/serialization/archives/XmlArchive.d:1342 #38 0x000000000040aa2d in orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject() (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at orange/serialization/Serializer.d:1152 #39 0x000000000040a947 in orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal() (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at orange/serialization/Serializer.d:1104 By the way, there are about 3 or 4 delegate context allocations within this cycles. |
February 15, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 15 Feb, 2012,at 11:25 AM, Martin Nowak <dawg at dawgfoto.de> wrote: > On Wed, 15 Feb 2012 08:52:52 +0100, Jacob Carlborg <doob at me.com> wrote: > > > On 15 Feb, 2012,at 01:35 AM, Martin Nowak <dawg at dawgfoto.de> wrote: > > > >> > I'm seeing some general problem with array appending Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending. > >> > > >> > >> Any futher insights on this? > >> Even a bigger test case would be helpful if it reproduces the error. > > Unfortunately no. I have a big test case: > > > > This example: http://pastebin.com/k1QQnhEp > > together with Orange: https://github.com/jacob-carlborg/orange > > > > Just place the example in the same folder as Orange and run it with RDMD.? > > I get an infinite recursion. > > Starting from > Serializer.d(1107): return deserializeObject!(T)(keyOrId); // with keyOrId > being "refme" the recursive field name in Foo > > #29 0x000000000040a947 in > orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal() > (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at > orange/serialization/Serializer.d:1104 > #30 0x000000000040ad53 in > orange.serialization.Serializer.Serializer.__T29objectStructDeserializeHelperTC4main3FooZ.objectStructDeserializeHelper() > (this=0x8006c4a00, value=<error reading variable>) at > orange/serialization/Serializer.d:1482 > #31 0x000000000040ac7e in > orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject() > (this=0x80128b1c0) at orange/serialization/Serializer.d:1181 > #32 0x000000000040a89f in > orange.serialization.Serializer.Serializer.__T13triggerEventsTC4main3FooZ.triggerEvents() > (this=0x8006c4a00, dg=0x000000000040aa94000000080128b1c0, > value=0x80128c860) at orange/serialization/Serializer.d:1749 > #33 0x000000000040aa8b in > orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject() > (this=0x80128b1c0) at orange/serialization/Serializer.d:1153 > #34 0x00000000004061cb in > orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject() > (this=0x80128b140) at orange/serialization/archives/XmlArchive.d:1366 > #35 0x0000000000417cdb in > orange.util.Use.__T7restoreTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.restore() > (this=0x0, value=0x8006c6f50, dg=0x000000000040603c000000080128b140) at > orange/util/Use.d:162 > #36 0x0000000000417b94 in > orange.util.Use.__T13RestoreStructTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.RestoreStruct.opIn() > (this=0x7fffffbffc20, deleg=0x000000000040603c000000080128b140) at > orange/util/Use.d:127 > #37 0x0000000000406035 in > orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject() > (this=0x8006c6f00, dg=..., result=0x80128b1c8, id=0x7fffffbffc98, > key=0x0000000000459eb00000000000000005) at > orange/serialization/archives/XmlArchive.d:1342 > #38 0x000000000040aa2d in > orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject() > (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at > orange/serialization/Serializer.d:1152 > #39 0x000000000040a947 in > orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal() > (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at > orange/serialization/Serializer.d:1104 > > > By the way, there are about 3 or 4 delegate context allocations within this cycles. Yeah, but the top of the backtrace looks like this: (gdb) bt #0 0x0000000100043f5c in D2gc3gcx3Gcx7getInfoMFPvZS2gc3gcx7BlkInfo () #1 0x0000000100042ecd in D2gc3gcx2GC11queryNoSyncMFPvZS2gc3gcx7BlkInfo () #2 0x0000000100042e1d in D2gc3gcx2GC5queryMFPvZS2gc3gcx7BlkInfo () #3 0x0000000100041400 in gc_query () #4 0x000000010004ae25 in _d_arrayappendcTX () #5 0x000000010000b7fa in D6orange3xml9PhobosXml7Element10attributesMFZAC6orange3xml9PhobosXml9Attribute17__foreachbody1521MFKAyaKAyaZi () #6 0x0000000100046ec6 in _aaApply2 () #7 0x000000010000b770 in D6orange3xml9PhobosXml7Element10attributesMFZAC6orange3xml9PhobosXml9Attribute () #8 0x0000000100001c83 in D6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4Node10attributesMFZS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument12VisitorProxy () #9 0x000000010000205e in D6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument10QueryProxy9attributeMFDFS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZbZS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument10QueryProxy At number 4 there's a call to _d_arrayappendcTX, which would be the array appending in this method: https://github.com/jacob-carlborg/orange/blob/master/orange/xml/PhobosXml.d#L764 If I remove that array append then? I get the same error somewhere else in the code. -- /Jacob Carlborg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120215/8105e09c/attachment.html> |
February 15, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | > Yeah, but the top of the backtrace looks like this:
>
It's a stack overflow, i.e. it will segfault wherever it wants to.
|
February 15, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 15 Feb, 2012,at 01:24 PM, Martin Nowak <dawg at dawgfoto.de> wrote: > > Yeah, but the top of the backtrace looks like this: > > > It's a stack overflow, i.e. it will segfault wherever it wants to. Then the question is?. Is this a bug in DMD or in my code since it worked with DMD 2.057. -- /Jacob Carlborg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120215/36025381/attachment-0001.html> |
February 15, 2012 [dmd-beta] D2 2.058 beta 4 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Wed, 15 Feb 2012 14:05:35 +0100, Jacob Carlborg <doob at me.com> wrote:
> On 15 Feb, 2012,at 01:24 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
>
>> > Yeah, but the top of the backtrace looks like this:
>> >
>> It's a stack overflow, i.e. it will segfault wherever it wants to.
> Then the question is?. Is this a bug in DMD or in my code since it worked with DMD 2.057.
>
> --
> /Jacob Carlborg
I get that stack overflow with 2.057 too.
|
Copyright © 1999-2021 by the D Language Foundation