Returning for a second back to the original purpose of this thread.. has the problem been identified?  It doesn't look like it, but figured I'd ask.

On 11/8/2010 2:12 PM, Walter Bright wrote:
> See my reply: http://d.puremagic.com/issues/show_bug.cgi?id=4854
> 
> Sean Kelly wrote:
>> The library code isn't different between OS versions so my guess is that this is somehow related to object file generation within the compiler. backend/machobj.c didn't change between May 10th and Jun 11th however, so I'm not sure what to suggest.  If it helps, here are the druntime and DMD timelines for DMD 2.047:
>>
>> http://dsource.org/projects/druntime/timeline?from=6%2F11%2F10&daysback=32&wiki=on&changeset=on&milestone=on&ticket=on&update=Update
>>
>> http://dsource.org/projects/dmd/timeline?from=6%2F11%2F10&daysback=32&wiki=on&changeset=on&milestone=on&ticket=on&update=Update
>>
>>
>> I don't see anything in the druntime changelog that should affect TLS.  The DMD changelog will take longer to go through though.
>>
>> On Nov 8, 2010, at 12:33 PM, Jacob Carlborg wrote:
>>
>> 
>>> I can reproduce the error using 2.050 on Mac OS X 10.5.8.
>>>
>>> On 8 nov 2010, at 20:02, Sean Kelly wrote:
>>>
>>> 
>>>> I can't reproduce using 2.050 and OSX 10.6.  Is anyone still on 10.5 that can try this with 2.050?
>>>>
>>>> On Nov 8, 2010, at 3:46 AM, Don Clugston wrote:
>>>>
>>>> 
>>>>> Bug 4854. "Regression(2.047, Mac only) writefln Segmentation fault if no globals"  Confirmed by 3 people.
>>>>>
>>>>> Thread local storage isn't getting set up correctly. Perhaps this
>>>>> happens when TLS is used in a library, but not in user code.
>>>>> This behaviour was introduced in 2.047, though it may have been a
>>>>> latent bug which was only triggered in that release.
>>>>> This may be a druntime bug, though it is more likely to be a compiler bug.
>>>>>
>>>>> Although this is OSX-specific, this bug could still be a PR disaster. Perhaps an OSX user can track down which svn commit triggered the regression.
>>>> 
>>> -- 
>>> /Jacob Carlborg
>>>

On 11/10/10 12:59 PM, Sean Kelly wrote:
> On Nov 10, 2010, at 12:44 PM, Andrei Alexandrescu wrote:
>>
>> I suggest we go with a hash. It costs next to nothing and has no future scalability money. I bet money at least a few companies (Facebook included) would run into severe scalability issues if linear search is to be used.
>
> I can't imagine an app would load more than a few dynamic libraries, and the data shouldn't need random access, should it?  Would performance really be an issue here?

I can't either. Then, I couldn't imagine a C++ application could have 50,000 global variables, until HPHP generated some. Turns out gcc does linear look-up for global variables, which severely affects compilation performance.

Andrei

Making it actually use reference counting (as well as cleaning up some bit rot to make it compile) aren't done yet.  They're on my todo list.

On Wed, Nov 10, 2010 at 4:04 PM, Robert Jacques <sandford at jhu.edu> wrote:

> On Wed, 10 Nov 2010 15:49:34 -0500, Jacob Carlborg <doob at me.com> wrote:
>
>>
>> I would prefer to use a hash as well but I don't know if the runtime is sufficiently initialized when this operation would be called. I guess Sean or Walter have to answer/decide this.
>>
>>
> David Simcha has put some work into alternative AA implementations, including a sealed one which should only require malloc/free.
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101110/e7ccaa4f/attachment.html>

Le 2010-11-10 ? 16:07, Brad Roberts a ?crit :

> Returning for a second back to the original purpose of this thread.. has the problem been identified?  It doesn't look like it, but figured I'd ask.

More or less. What's clear is that the three-section (begin, content, end) trick is not very reliable on Mac OS X because of the linker, and it doesn't appear consistent across different OS versions (this bug seem to be 10.5.x only). The solution that is expected to work is to replace the three-section trick with something more reliable.

It's true that the discussion has extended to support of dynamic libraries. That's mainly because loading a library involves the same process about finding the address and size for different segments in the library, and the solution was inspired from code meant to work with dynamic libraries.

If all we wanted was to fix this bug, probably calling this function to get the address and size of a section instead of the current method would be enough:

	char* getsectdata(
	  const char* segname,
	  const char* sectname,
	  unsigned long* size);

It won't work with dynamic libraries, but I'd expect the hello world crash on 10.5.x to disappear.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On 11/10/2010 4:29 PM, Michel Fortin wrote:
> Le 2010-11-10 ? 16:07, Brad Roberts a ?crit :
> 
>> Returning for a second back to the original purpose of this thread.. has the problem been identified?  It doesn't look like it, but figured I'd ask.
> 
> More or less. What's clear is that the three-section (begin, content, end) trick is not very reliable on Mac OS X because of the linker, and it doesn't appear consistent across different OS versions (this bug seem to be 10.5.x only). The solution that is expected to work is to replace the three-section trick with something more reliable.
> 
> It's true that the discussion has extended to support of dynamic libraries. That's mainly because loading a library involves the same process about finding the address and size for different segments in the library, and the solution was inspired from code meant to work with dynamic libraries.
> 
> If all we wanted was to fix this bug, probably calling this function to get the address and size of a section instead of the current method would be enough:
> 
> 	char* getsectdata(
> 	  const char* segname,
> 	  const char* sectname,
> 	  unsigned long* size);
> 
> It won't work with dynamic libraries, but I'd expect the hello world crash on 10.5.x to disappear.

Personally, I'm not impacted by any osx issues, but given the severity of the failure for those that do use 10.5, I'd like to see a fix in the next release. Either a big one or a temporary one, but something.  It'd probably be good to try a quick fix, in case the larger set of changes take a while.

My 2 cents,
Brad

Michel's summary of the situation is correct, and I agree with Brad's suggestion. Let's roll out the fix to this specific problem, and worry about engineering shared library support as a separate issue.

Brad Roberts wrote:
> On 11/10/2010 4:29 PM, Michel Fortin wrote:
> 
>> Le 2010-11-10 ? 16:07, Brad Roberts a ?crit :
>>
>> 
>>> Returning for a second back to the original purpose of this thread.. has the
>>> problem been identified?  It doesn't look like it, but figured I'd ask.
>>> 
>> More or less. What's clear is that the three-section (begin, content, end) trick is not very reliable on Mac OS X because of the linker, and it doesn't appear consistent across different OS versions (this bug seem to be 10.5.x only). The solution that is expected to work is to replace the three-section trick with something more reliable.
>>
>> It's true that the discussion has extended to support of dynamic libraries. That's mainly because loading a library involves the same process about finding the address and size for different segments in the library, and the solution was inspired from code meant to work with dynamic libraries.
>>
>> If all we wanted was to fix this bug, probably calling this function to get the address and size of a section instead of the current method would be enough:
>>
>> 	char* getsectdata(
>> 	  const char* segname,
>> 	  const char* sectname,
>> 	  unsigned long* size);
>>
>> It won't work with dynamic libraries, but I'd expect the hello world crash on 10.5.x to disappear.
>> 
>
> Personally, I'm not impacted by any osx issues, but given the severity of the failure for those that do use 10.5, I'd like to see a fix in the next release. Either a big one or a temporary one, but something.  It'd probably be good to try a quick fix, in case the larger set of changes take a while.
>
> My 2 cents,
> Brad
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> 

I've created a patch but it doesn't solve the problem: http://tango.pastebin.com/Pn2tVjSm . I don't get an error in __tls_get_addr now but instead I get this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x97655133 in strncmp ()
(gdb) bt
#0  0x97655133 in strncmp ()
#1  0x0000101c in ?? ()
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb)

Maybe someone else can look at the patch and see if I did something wrong or maybe the solution we thought of couldn't fix the problem.

On 9 nov 2010, at 21:27, Jacob Carlborg wrote:

> I'll see what I can do.
> 
> On 9 nov 2010, at 20:55, Walter Bright wrote:
> 
>> 
>> 
>> Jacob Carlborg wrote:
>>> It should work using getsectdatafromheader, that's what I changed when I added support for dynamic libraries to Tango. Have a look at the Tango code: http://dsource.org/projects/tango/browser/trunk/tango/core/rt/compiler/dmd/object_.d#L1270 and http://dsource.org/projects/tango/browser/trunk/tango/core/rt/compiler/dmd/darwin/Image.d#L103 . The file in the last link is completely made by me so you won't have to be afraid for looking at it. Or if you don't want to look at Tango source files at all you can look at this druntime change: http://www.dsource.org/projects/druntime/changeset/372 , to be more specific: http://www.dsource.org/projects/druntime/browser/trunk/src/rt/image.d?rev=372#L105
>>> 
>>> 
>> 
>> Thanks, Jacob! If you want to submit a patch to druntime that, for OSX, eliminates the dependence on the begin and end sections, that would be awesome.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> -- 
> /Jacob Carlborg
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

I forgot to add:

I'm still using an array, too many dependencies expected it to be an array. Also I don't remove anything when a library is unloaded although I put in a empty function for that.

On 11 nov 2010, at 15:34, Jacob Carlborg wrote:

> I've created a patch but it doesn't solve the problem: http://tango.pastebin.com/Pn2tVjSm . I don't get an error in __tls_get_addr now but instead I get this:
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> 0x97655133 in strncmp ()
> (gdb) bt
> #0  0x97655133 in strncmp ()
> #1  0x0000101c in ?? ()
> Previous frame inner to this frame (gdb could not unwind past this frame)
> (gdb)
> 
> Maybe someone else can look at the patch and see if I did something wrong or maybe the solution we thought of couldn't fix the problem.
> 
> On 9 nov 2010, at 21:27, Jacob Carlborg wrote:
> 
>> I'll see what I can do.
>> 
>> On 9 nov 2010, at 20:55, Walter Bright wrote:
>> 
>>> 
>>> 
>>> Jacob Carlborg wrote:
>>>> It should work using getsectdatafromheader, that's what I changed when I added support for dynamic libraries to Tango. Have a look at the Tango code: http://dsource.org/projects/tango/browser/trunk/tango/core/rt/compiler/dmd/object_.d#L1270 and http://dsource.org/projects/tango/browser/trunk/tango/core/rt/compiler/dmd/darwin/Image.d#L103 . The file in the last link is completely made by me so you won't have to be afraid for looking at it. Or if you don't want to look at Tango source files at all you can look at this druntime change: http://www.dsource.org/projects/druntime/changeset/372 , to be more specific: http://www.dsource.org/projects/druntime/browser/trunk/src/rt/image.d?rev=372#L105
>>>> 
>>>> 
>>> 
>>> Thanks, Jacob! If you want to submit a patch to druntime that, for OSX, eliminates the dependence on the begin and end sections, that would be awesome.
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> -- 
>> /Jacob Carlborg
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> -- 
> /Jacob Carlborg
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg