Mac: 3.0.dylib error.

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Mac: 3.0.dylib error.

James Crook
Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on
developer machines:

> Starting Variant B with CFG set to Classic Theme gives this crash
> Dyld Error Message:
>    Library not loaded: /usr/local/lib/libwx_osx_cocoau_release_core-3.0.dylib
>    Referenced from: /Applications/Audacity 220 July 23 B/Audacity.app/Contents/MacOS/Audacity
>    Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe764849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the
issue down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc78c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes
that may tell us what the real problem is.

--James.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli


On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
Cliff, Peter and Bill narrowed down a Mac crash error to a particular commit by me:

This is the crash.  Only on machines without the library, not on developer machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
   Library not loaded: /usr/local/lib/libwx_osx_cocoau_release_core-3.0.dylib
   Referenced from: /Applications/Audacity 220 July 23 B/Audacity.app/Contents/MacOS/Audacity
   Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe764849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed bitmap stored as numbers embedded in the executable. There is no way it should be changing which libraries get loaded. In order to narrow the issue down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc78c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it 'fixes' the issue on Mac, and we can then investigate further changes that may tell us what the real problem is.

--James.

I observe this in the debugger.

After your latest the sizes of the four static cache arrays in Theme.cpp 
67875 for Dark
70514 for Light
47173 for Classic
69332 for HiContrast

Shouldn't they all be the same size?

And light is 70112 before the change.

Maybe not relevant to the crash but it surprised me.  But maybe some simple comrpression of images like run-length encoding explains it?

PRL



 



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli
In reply to this post by James Crook


On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
Cliff, Peter and Bill narrowed down a Mac crash error to a particular commit by me:

This is the crash.  Only on machines without the library, not on developer machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
   Library not loaded: /usr/local/lib/libwx_osx_cocoau_release_core-3.0.dylib
   Referenced from: /Applications/Audacity 220 July 23 B/Audacity.app/Contents/MacOS/Audacity
   Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe764849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed bitmap stored as numbers embedded in the executable. There is no way it should be changing which libraries get loaded. In order to narrow the issue down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc78c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it 'fixes' the issue on Mac, and we can then investigate further changes that may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good evidence for this bisection, consistent crashes in one build and not another, provided that preferences choose Light theme?

And here is a wild guess for a simple fix of it.  Remove "const" from the declarations of the four static arrays in Theme.cpp.  Then maybe the linker puts those tables somewhere else, and the subtle bug in macOs, if that's what it is, will be averted.

Maybe though we might need a more difficult fix involving memory mapped files, and bundling these compressed images as resources.

PRL

 



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

James Crook
In reply to this post by Paul Licameli
On 7/26/2017 2:53 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook [hidden email] wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
   Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
   Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
   Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes that
may tell us what the real problem is.

--James.

I observe this in the debugger.

After your latest the sizes of the four static cache arrays in Theme.cpp
67875 for Dark
70514 for Light
47173 for Classic
69332 for HiContrast

Shouldn't they all be the same size?

And light is 70112 before the change.

Maybe not relevant to the crash but it surprised me.  But maybe some simple
comrpression of images like run-length encoding explains it?
Compression used by PNG format (deflate) explains it.


PRL







------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Cliff Scott
Just forwarded Bill's test of a new build including everything including James' reversion to James. It launches normally now.

Cliff

On Jul 26, 2017, at 9:11 AM, James Crook <[hidden email]> wrote:

On 7/26/2017 2:53 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook [hidden email] wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
   Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
   Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
   Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes that
may tell us what the real problem is.

--James.

I observe this in the debugger.

After your latest the sizes of the four static cache arrays in Theme.cpp
67875 for Dark
70514 for Light
47173 for Classic
69332 for HiContrast

Shouldn't they all be the same size?

And light is 70112 before the change.

Maybe not relevant to the crash but it surprised me.  But maybe some simple
comrpression of images like run-length encoding explains it?
Compression used by PNG format (deflate) explains it.

PRL






------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

James Crook
In reply to this post by Paul Licameli
On 7/26/2017 3:09 PM, Paul Licameli wrote:

> On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
>
>> Cliff, Peter and Bill narrowed down a Mac crash error to a particular
>> commit by me:
>>
>> This is the crash.  Only on machines without the library, not on developer
>> machines:
>>
>> Starting Variant B with CFG set to Classic Theme gives this crash
>>> Dyld Error Message:
>>>     Library not loaded: /usr/local/lib/libwx_osx_cocoa
>>> u_release_core-3.0.dylib
>>>     Referenced from: /Applications/Audacity 220 July 23
>>> B/Audacity.app/Contents/MacOS/Audacity
>>>     Reason: image not found
>>>
>> And the commit that triggers it is:
>>
>> https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
>> 64849791f72a742081285574
>>
>> This is totally mysterious to me.  The change is 'only' to a compressed
>> bitmap stored as numbers embedded in the executable. There is no way it
>> should be changing which libraries get loaded. In order to narrow the issue
>> down, I have reverted the change with this commit:
>>
>> https://github.com/audacity/audacity/commit/c316f8122b188cc7
>> 8c703f3261de2d683383d635
>>
>> The theme will now have a rather too grey background.  Hopefully it
>> 'fixes' the issue on Mac, and we can then investigate further changes that
>> may tell us what the real problem is.
>>
>> --James.
>>
> I did not follow in detail.  Do I understand that there is good evidence
> for this bisection, consistent crashes in one build and not another,
> provided that preferences choose Light theme?
I think the evidence is weakish.  The build crashes are consistent - the
build before is OK, the build itself and those tried after crash.  
That's consistent, but is not dependent on what theme is selected.
If builds of current head which has reverted data don't crash, then that
is reasonably strong evidence that the data is causing the issue.


> And here is a wild guess for a simple fix of it.  Remove "const" from the
> declarations of the four static arrays in Theme.cpp.  Then maybe the linker
> puts those tables somewhere else, and the subtle bug in macOs, if that's
> what it is, will be averted.
If that does fix it I would be worried!  It shows something unknown
going on.
Definitely worth trying.   If it does fix it, we should look at other
things after doing that to try to narrow down the root cause.

> Maybe though we might need a more difficult fix involving memory mapped
> files, and bundling these compressed images as resources.
I don't think that would be good if we are still uncertain about the
root cause.

--James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

James Crook
In reply to this post by Cliff Scott
That's good news, since it tends to confirm that - strange as it seems - it is the data causing the issue.

To further test and confirm the root cause, I've re-instated the LightTheme fix and per Paul's suggestion removed the const. 

IF this does not crash, then it is something to do with having that data in the const section.
IF this does crash, (on all themes), then I am baffled.

--James.




On 7/26/2017 3:21 PM, Cliff Scott wrote:
Just forwarded Bill's test of a new build including everything including James' reversion to James. It launches normally now.

Cliff

On Jul 26, 2017, at 9:11 AM, James Crook [hidden email] wrote:

On 7/26/2017 2:53 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook [hidden email] [hidden email] wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
   Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
   Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
   Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7 <https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7>
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7 <https://github.com/audacity/audacity/commit/c316f8122b188cc7>
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes that
may tell us what the real problem is.

--James.

I observe this in the debugger.

After your latest the sizes of the four static cache arrays in Theme.cpp
67875 for Dark
70514 for Light
47173 for Classic
69332 for HiContrast

Shouldn't they all be the same size?

And light is 70112 before the change.

Maybe not relevant to the crash but it surprised me.  But maybe some simple
comrpression of images like run-length encoding explains it?
Compression used by PNG format (deflate) explains it.

PRL






------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
_______________________________________________
audacity-devel mailing list
[hidden email] [hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel <https://lists.sourceforge.net/lists/listinfo/audacity-devel>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>

_______________________________________________
audacity-devel mailing list
[hidden email] [hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel <https://lists.sourceforge.net/lists/listinfo/audacity-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli
In reply to this post by James Crook


On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:
On 7/26/2017 3:09 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
    Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
    Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
    Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good evidence
for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?
I think the evidence is weakish.  The build crashes are consistent - the build before is OK, the build itself and those tried after crash.  That's consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the theme data changed?

But remind me why we thought the configuration file had any influence on the bug?

Which seems really bizarre, because I think the loading of the dynamic libraries happens very early in the process, before we come near any code that uses the theme data arrays.  How could this influence what happens earlier in the process?

Unless, good grief, somehow the previous run of the program influences the occurrence of the bug in the next?

Or is configuration setting a red herring?  Is there intermittent non-occurrence of it because of who knows what subtleties in the operating system?

PRL

 
If builds of current head which has reverted data don't crash, then that is reasonably strong evidence that the data is causing the issue.


And here is a wild guess for a simple fix of it.  Remove "const" from the
declarations of the four static arrays in Theme.cpp.  Then maybe the linker
puts those tables somewhere else, and the subtle bug in macOs, if that's
what it is, will be averted.
If that does fix it I would be worried!  It shows something unknown going on.
Definitely worth trying.   If it does fix it, we should look at other things after doing that to try to narrow down the root cause.

Maybe though we might need a more difficult fix involving memory mapped
files, and bundling these compressed images as resources.
I don't think that would be good if we are still uncertain about the root cause.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Bill Wharrie

On 2017/07/26, at 11:47 AM, Paul Licameli <[hidden email]> wrote:



On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:
On 7/26/2017 3:09 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
    Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
    Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
    Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good evidence
for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?
I think the evidence is weakish.  The build crashes are consistent - the build before is OK, the build itself and those tried after crash.  That's consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the theme data changed?

But remind me why we thought the configuration file had any influence on the bug?

Which seems really bizarre, because I think the loading of the dynamic libraries happens very early in the process, before we come near any code that uses the theme data arrays.  How could this influence what happens earlier in the process?

Unless, good grief, somehow the previous run of the program influences the occurrence of the bug in the next?

Or is configuration setting a red herring? 

Yes, it is. When launching without a CFG the CFG file is not created before the crash.
— Bill


Is there intermittent non-occurrence of it because of who knows what subtleties in the operating system?

PRL

 
If builds of current head which has reverted data don't crash, then that is reasonably strong evidence that the data is causing the issue.


And here is a wild guess for a simple fix of it.  Remove "const" from the
declarations of the four static arrays in Theme.cpp.  Then maybe the linker
puts those tables somewhere else, and the subtle bug in macOs, if that's
what it is, will be averted.
If that does fix it I would be worried!  It shows something unknown going on.
Definitely worth trying.   If it does fix it, we should look at other things after doing that to try to narrow down the root cause.

Maybe though we might need a more difficult fix involving memory mapped
files, and bundling these compressed images as resources.
I don't think that would be good if we are still uncertain about the root cause.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

James Crook
In reply to this post by Paul Licameli
On 7/26/2017 4:47 PM, Paul Licameli wrote:

> On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:
>
>> On 7/26/2017 3:09 PM, Paul Licameli wrote:
>>
>>> On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
>>>
>>> Cliff, Peter and Bill narrowed down a Mac crash error to a particular
>>>> commit by me:
>>>>
>>>> This is the crash.  Only on machines without the library, not on
>>>> developer
>>>> machines:
>>>>
>>>> Starting Variant B with CFG set to Classic Theme gives this crash
>>>>
>>>>> Dyld Error Message:
>>>>>      Library not loaded: /usr/local/lib/libwx_osx_cocoa
>>>>> u_release_core-3.0.dylib
>>>>>      Referenced from: /Applications/Audacity 220 July 23
>>>>> B/Audacity.app/Contents/MacOS/Audacity
>>>>>      Reason: image not found
>>>>>
>>>>> And the commit that triggers it is:
>>>> https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
>>>> 64849791f72a742081285574
>>>>
>>>> This is totally mysterious to me.  The change is 'only' to a compressed
>>>> bitmap stored as numbers embedded in the executable. There is no way it
>>>> should be changing which libraries get loaded. In order to narrow the
>>>> issue
>>>> down, I have reverted the change with this commit:
>>>>
>>>> https://github.com/audacity/audacity/commit/c316f8122b188cc7
>>>> 8c703f3261de2d683383d635
>>>>
>>>> The theme will now have a rather too grey background.  Hopefully it
>>>> 'fixes' the issue on Mac, and we can then investigate further changes
>>>> that
>>>> may tell us what the real problem is.
>>>>
>>>> --James.
>>>>
>>>> I did not follow in detail.  Do I understand that there is good evidence
>>> for this bisection, consistent crashes in one build and not another,
>>> provided that preferences choose Light theme?
>>>
>> I think the evidence is weakish.  The build crashes are consistent - the
>> build before is OK, the build itself and those tried after crash.  That's
>> consistent, but is not dependent on what theme is selected.
>>
> So I understand bisection clearly implicates a commit in which only the
> theme data changed?
That and the recent 'fix' (your idea of not using the const) does now.

> But remind me why we thought the configuration file had any influence on
> the bug?
I thought the way that that (exact) data could cause a problem via
memory corruption would be if wxMemoryInputStream was the villain, and
the data tickled its bug.  BUT that could only happen if the Light Theme
and its data were used.  Since the crash happened when config file had
Dark theme set, that ruled out processing of the data as being the
problem.  It's its existence that is the issue.

> Which seems really bizarre, because I think the loading of the dynamic
> libraries happens very early in the process, before we come near any code
> that uses the theme data arrays.  How could this influence what happens
> earlier in the process?
You're right, and that's another reason pointing to it being the data
itself that is the problem.  I had in mind delayed loading of dlls, e.g.
if loaded only when needed.  But wxWidgets modules are loaded early.

It doesn't seem to be that we have too much const data.
Perhaps there is a certain size and positioning that causes some issue.
Perhaps there is something to do with paths that is being messed up.  It
might even be another symptom of
http://bugzilla.audacityteam.org/show_bug.cgi?id=1567 if something is
messing with search paths.

--James.

> Unless, good grief, somehow the previous run of the program influences the
> occurrence of the bug in the next?
No evidence for that yet.  My impression from the reports is that the
builds run OK or crash 'reliably'.


> Or is configuration setting a red herring?
A red herring.  A hypothesis refuted by Bill's Dark theme results.
> Is there intermittent non-occurrence of it because of who knows what subtleties in the operating system?
No evidence (yet) of intermittent non-occurence for the same build.

--James.


>
> PRL
>
>
>
>> If builds of current head which has reverted data don't crash, then that
>> is reasonably strong evidence that the data is causing the issue.
>>
>>
>> And here is a wild guess for a simple fix of it.  Remove "const" from the
>>> declarations of the four static arrays in Theme.cpp.  Then maybe the
>>> linker
>>> puts those tables somewhere else, and the subtle bug in macOs, if that's
>>> what it is, will be averted.
>>>
>> If that does fix it I would be worried!  It shows something unknown going
>> on.
>> Definitely worth trying.   If it does fix it, we should look at other
>> things after doing that to try to narrow down the root cause.
>>
>> Maybe though we might need a more difficult fix involving memory mapped
>>> files, and bundling these compressed images as resources.
>>>
>> I don't think that would be good if we are still uncertain about the root
>> cause.
>>
>> --James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli
In reply to this post by James Crook


On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:
On 7/26/2017 3:09 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash
Dyld Error Message:
    Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
    Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
    Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good evidence
for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?
I think the evidence is weakish.  The build crashes are consistent - the build before is OK, the build itself and those tried after crash.  That's consistent, but is not dependent on what theme is selected.
If builds of current head which has reverted data don't crash, then that is reasonably strong evidence that the data is causing the issue.


And here is a wild guess for a simple fix of it.  Remove "const" from the
declarations of the four static arrays in Theme.cpp.  Then maybe the linker
puts those tables somewhere else, and the subtle bug in macOs, if that's
what it is, will be averted.
If that does fix it I would be worried!  It shows something unknown going on.
Definitely worth trying.   If it does fix it, we should look at other things after doing that to try to narrow down the root cause.

I built release and navigated to the folder with the excutable and did this, which shows the problem arrays are not in the T, text section but rather in an s, "other" section, according to man nm.  And this is WITHOUT striking const.  Who knows, I am out of my depth here, maybe there is a special seciton for "big things" apart from the usual T.

Pauls-MacBook-Pro:MacOS paullicameli$ nm Audacity | grep -i ImageCache

0090a250 s __ZL20DarkImageCacheAsData

0091ab73 s __ZL21LightImageCacheAsData

0092bd53 s __ZL23ClassicImageCacheAsData

00937598 s __ZL26HiContrastImageCacheAsData

003659c0 T __ZN9ThemeBase14ReadImageCacheE11teThemeTypeb

00369400 T __ZN9ThemeBase16CreateImageCacheEb

Pauls-MacBook-Pro:MacOS paullicameli$ 

 
But now see the results when I do strike the four const's and change nothing else in source.


Pauls-MacBook-Pro:MacOS paullicameli$ nm Audacity | grep -i ImageCache

00c59978 d __ZL20DarkImageCacheAsData

00c6a29b d __ZL21LightImageCacheAsData

00c7b47b d __ZL23ClassicImageCacheAsData

00c86cc0 d __ZL26HiContrastImageCacheAsData

00365be0 T __ZN9ThemeBase14ReadImageCacheE11teThemeTypeb

00369620 T __ZN9ThemeBase16CreateImageCacheEb


D means data section, and lowercase means static.  It seems the arrays certainly moved.

PRL




Maybe though we might need a more difficult fix involving memory mapped
files, and bundling these compressed images as resources.
I don't think that would be good if we are still uncertain about the root cause.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli
In reply to this post by James Crook


On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:
On 7/26/2017 4:47 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:

On 7/26/2017 3:09 PM, Paul Licameli wrote:

On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on
developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash

Dyld Error Message:
     Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
     Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
     Reason: image not found

And the commit that triggers it is:
https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the
issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes
that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good evidence
for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?

I think the evidence is weakish.  The build crashes are consistent - the
build before is OK, the build itself and those tried after crash.  That's
consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the
theme data changed?
That and the recent 'fix' (your idea of not using the const) does now.

But remind me why we thought the configuration file had any influence on
the bug?
I thought the way that that (exact) data could cause a problem via memory corruption would be if wxMemoryInputStream was the villain,

You mean you peeked inside that class, as I did, and saw a suspicious const_cast in the constructor, and wondered if a wxW bug writes to read-only data?  But I did not go deeply enough to confirm such a suspicion.
 
and the data tickled its bug.  BUT that could only happen if the Light Theme and its data were used.  Since the crash happened when config file had Dark theme set, that ruled out processing of the data as being the problem.  It's its existence that is the issue.

Which seems really bizarre, because I think the loading of the dynamic
libraries happens very early in the process, before we come near any code
that uses the theme data arrays.  How could this influence what happens
earlier in the process?
You're right, and that's another reason pointing to it being the data itself that is the problem.  I had in mind delayed loading of dlls, e.g. if loaded only when needed.  But wxWidgets modules are loaded early.

I should have recalled it sooner:  Audacity does do something weird at startup.  Remember how it uses fork and exec.  And it did that even before we wrote our partial fixes for Bug 1567.

Relevant old commits with fork and execve:
a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
[9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving functions around I think]
[b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork

That earliest was for fixing bug 543 http://bugzilla.audacityteam.org/show_bug.cgi?id=543  See especially Comment 1 there.  Hmmmm....

PRL


 

It doesn't seem to be that we have too much const data.
Perhaps there is a certain size and positioning that causes some issue.
Perhaps there is something to do with paths that is being messed up.  It might even be another symptom of http://bugzilla.audacityteam.org/show_bug.cgi?id=1567 if something is messing with search paths.

--James.

Unless, good grief, somehow the previous run of the program influences the
occurrence of the bug in the next?
No evidence for that yet.  My impression from the reports is that the builds run OK or crash 'reliably'.


Or is configuration setting a red herring?
A red herring.  A hypothesis refuted by Bill's Dark theme results.
Is there intermittent non-occurrence of it because of who knows what subtleties in the operating system?
No evidence (yet) of intermittent non-occurence for the same build.

--James.




PRL



If builds of current head which has reverted data don't crash, then that
is reasonably strong evidence that the data is causing the issue.


And here is a wild guess for a simple fix of it.  Remove "const" from the
declarations of the four static arrays in Theme.cpp.  Then maybe the
linker
puts those tables somewhere else, and the subtle bug in macOs, if that's
what it is, will be averted.

If that does fix it I would be worried!  It shows something unknown going
on.
Definitely worth trying.   If it does fix it, we should look at other
things after doing that to try to narrow down the root cause.

Maybe though we might need a more difficult fix involving memory mapped
files, and bundling these compressed images as resources.

I don't think that would be good if we are still uncertain about the root
cause.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli


On Wed, Jul 26, 2017 at 12:24 PM, Paul Licameli <[hidden email]> wrote:


On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:
On 7/26/2017 4:47 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:

On 7/26/2017 3:09 PM, Paul Licameli wrote:

On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:

Cliff, Peter and Bill narrowed down a Mac crash error to a particular
commit by me:

This is the crash.  Only on machines without the library, not on
developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash

Dyld Error Message:
     Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
     Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
     Reason: image not found

And the commit that triggers it is:
https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a compressed
bitmap stored as numbers embedded in the executable. There is no way it
should be changing which libraries get loaded. In order to narrow the
issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes
that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good evidence
for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?

I think the evidence is weakish.  The build crashes are consistent - the
build before is OK, the build itself and those tried after crash.  That's
consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the
theme data changed?
That and the recent 'fix' (your idea of not using the const) does now.

But remind me why we thought the configuration file had any influence on
the bug?
I thought the way that that (exact) data could cause a problem via memory corruption would be if wxMemoryInputStream was the villain,

You mean you peeked inside that class, as I did, and saw a suspicious const_cast in the constructor, and wondered if a wxW bug writes to read-only data?  But I did not go deeply enough to confirm such a suspicion.
 
and the data tickled its bug.  BUT that could only happen if the Light Theme and its data were used.  Since the crash happened when config file had Dark theme set, that ruled out processing of the data as being the problem.  It's its existence that is the issue.

Which seems really bizarre, because I think the loading of the dynamic
libraries happens very early in the process, before we come near any code
that uses the theme data arrays.  How could this influence what happens
earlier in the process?
You're right, and that's another reason pointing to it being the data itself that is the problem.  I had in mind delayed loading of dlls, e.g. if loaded only when needed.  But wxWidgets modules are loaded early.

I should have recalled it sooner:  Audacity does do something weird at startup.  Remember how it uses fork and exec.  And it did that even before we wrote our partial fixes for Bug 1567.

Relevant old commits with fork and execve:
a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
[9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving functions around I think]
[b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork

That earliest was for fixing bug 543 http://bugzilla.audacityteam.org/show_bug.cgi?id=543  See especially Comment 1 there.  Hmmmm....

PRL

So what if we tried a build, in which you don't remove const, but you do skip the fork and execve?

If that still crashes, we might eliminate the execve as the suspect.

If it doesn't, then maybe execve is part of the cause.  Or still maybe not, maybe the little disturbance to the executable image size or contents is what influences it.

If exeve is possibly the cause, I don't have an idea what to do about it.  That fork fix was decided to be very necessary to mitigate bug 1567 as much as we can, and that bug was something holding up the previous release.  We need it.

PRL

 


 

It doesn't seem to be that we have too much const data.
Perhaps there is a certain size and positioning that causes some issue.
Perhaps there is something to do with paths that is being messed up.  It might even be another symptom of http://bugzilla.audacityteam.org/show_bug.cgi?id=1567 if something is messing with search paths.

--James.

Unless, good grief, somehow the previous run of the program influences the
occurrence of the bug in the next?
No evidence for that yet.  My impression from the reports is that the builds run OK or crash 'reliably'.


Or is configuration setting a red herring?
A red herring.  A hypothesis refuted by Bill's Dark theme results.
Is there intermittent non-occurrence of it because of who knows what subtleties in the operating system?
No evidence (yet) of intermittent non-occurence for the same build.

--James.




PRL



If builds of current head which has reverted data don't crash, then that
is reasonably strong evidence that the data is causing the issue.


And here is a wild guess for a simple fix of it.  Remove "const" from the
declarations of the four static arrays in Theme.cpp.  Then maybe the
linker
puts those tables somewhere else, and the subtle bug in macOs, if that's
what it is, will be averted.

If that does fix it I would be worried!  It shows something unknown going
on.
Definitely worth trying.   If it does fix it, we should look at other
things after doing that to try to narrow down the root cause.

Maybe though we might need a more difficult fix involving memory mapped
files, and bundling these compressed images as resources.

I don't think that would be good if we are still uncertain about the root
cause.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Henric Jungheim
In reply to this post by Paul Licameli
On Wed, Jul 26, 2017 at 12:24:03PM -0400, Paul Licameli wrote:

> On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:
>
> > On 7/26/2017 4:47 PM, Paul Licameli wrote:
> >
> >> On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:
> >>
> >> On 7/26/2017 3:09 PM, Paul Licameli wrote:
> >>>
> >>> On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
> >>>>
> >>>> Cliff, Peter and Bill narrowed down a Mac crash error to a particular
> >>>>
> >>>>> commit by me:
> >>>>>
> >>>>> This is the crash.  Only on machines without the library, not on
> >>>>> developer
> >>>>> machines:
> >>>>>
> >>>>> Starting Variant B with CFG set to Classic Theme gives this crash
> >>>>>
> >>>>> Dyld Error Message:
> >>>>>>      Library not loaded: /usr/local/lib/libwx_osx_cocoa
> >>>>>> u_release_core-3.0.dylib
> >>>>>>      Referenced from: /Applications/Audacity 220 July 23
> >>>>>> B/Audacity.app/Contents/MacOS/Audacity
> >>>>>>      Reason: image not found
> >>>>>>
> >>>>>> And the commit that triggers it is:
> >>>>>>
> >>>>> https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
> >>>>> 64849791f72a742081285574
> >>>>>
> >>>>> This is totally mysterious to me.  The change is 'only' to a compressed
> >>>>> bitmap stored as numbers embedded in the executable. There is no way it
> >>>>> should be changing which libraries get loaded. In order to narrow the
> >>>>> issue
> >>>>> down, I have reverted the change with this commit:
> >>>>>
> >>>>> https://github.com/audacity/audacity/commit/c316f8122b188cc7
> >>>>> 8c703f3261de2d683383d635
> >>>>>
> >>>>> The theme will now have a rather too grey background.  Hopefully it
> >>>>> 'fixes' the issue on Mac, and we can then investigate further changes
> >>>>> that
> >>>>> may tell us what the real problem is.
> >>>>>
> >>>>> --James.
> >>>>>
> >>>>> I did not follow in detail.  Do I understand that there is good
> >>>>> evidence
> >>>>>
> >>>> for this bisection, consistent crashes in one build and not another,
> >>>> provided that preferences choose Light theme?
> >>>>
> >>>> I think the evidence is weakish.  The build crashes are consistent - the
> >>> build before is OK, the build itself and those tried after crash.  That's
> >>> consistent, but is not dependent on what theme is selected.
> >>>
> >>> So I understand bisection clearly implicates a commit in which only the
> >> theme data changed?
> >>
> > That and the recent 'fix' (your idea of not using the const) does now.
> >
> > But remind me why we thought the configuration file had any influence on
> >> the bug?
> >>
> > I thought the way that that (exact) data could cause a problem via memory
> > corruption would be if wxMemoryInputStream was the villain,
>
>
> You mean you peeked inside that class, as I did, and saw a suspicious
> const_cast in the constructor, and wondered if a wxW bug writes to
> read-only data?  But I did not go deeply enough to confirm such a suspicion.

A write to data in a read-only section should be obvious;
there should be a segfault.  Does the Mac Audacity try to
catch such things (for error reporting or what-not)?

Does running Audacity under "dtruss -f" show anything odd?

This should distinguish between the section layout and if
the "const"ness itself is causing a problem: Keep the data
const, but copy it to a writable memory buffer before
passing it to wxMemoryInputStream.  If it is something to do
with the layout, then "static const ABunchOfConstData[5 *
1024 * 1024] = { 1 };" would presumable be enough to cause
grief (assuming the linker isn't clever enough to eliminate
unreferenced data).

>
>
> > and the data tickled its bug.  BUT that could only happen if the Light
> > Theme and its data were used.  Since the crash happened when config file
> > had Dark theme set, that ruled out processing of the data as being the
> > problem.  It's its existence that is the issue.
> >
> > Which seems really bizarre, because I think the loading of the dynamic
> >> libraries happens very early in the process, before we come near any code
> >> that uses the theme data arrays.  How could this influence what happens
> >> earlier in the process?
> >>
> > You're right, and that's another reason pointing to it being the data
> > itself that is the problem.  I had in mind delayed loading of dlls, e.g. if
> > loaded only when needed.  But wxWidgets modules are loaded early.
> >
>
> I should have recalled it sooner:  Audacity does do something weird at
> startup.  Remember how it uses fork and exec.  And it did that even before
> we wrote our partial fixes for Bug 1567.
>
> Relevant old commits with fork and execve:
> a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
> [9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving functions
> around I think]
> [b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
> 36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork
>
> That earliest was for fixing bug 543
> http://bugzilla.audacityteam.org/show_bug.cgi?id=543  See especially
> Comment 1 there.  Hmmmm....
>
> PRL
>
>
>
>
> >
> > It doesn't seem to be that we have too much const data.
> > Perhaps there is a certain size and positioning that causes some issue.
> > Perhaps there is something to do with paths that is being messed up.  It
> > might even be another symptom of http://bugzilla.audacityteam.o
> > rg/show_bug.cgi?id=1567 if something is messing with search paths.
> >
> > --James.
> >
> > Unless, good grief, somehow the previous run of the program influences the
> >> occurrence of the bug in the next?
> >>
> > No evidence for that yet.  My impression from the reports is that the
> > builds run OK or crash 'reliably'.
> >
> >
> > Or is configuration setting a red herring?
> >>
> > A red herring.  A hypothesis refuted by Bill's Dark theme results.
> >
> >> Is there intermittent non-occurrence of it because of who knows what
> >> subtleties in the operating system?
> >>
> > No evidence (yet) of intermittent non-occurence for the same build.
> >
> > --James.
> >
> >
> >
> >
> >> PRL
> >>
> >>
> >>
> >> If builds of current head which has reverted data don't crash, then that
> >>> is reasonably strong evidence that the data is causing the issue.
> >>>
> >>>
> >>> And here is a wild guess for a simple fix of it.  Remove "const" from the
> >>>
> >>>> declarations of the four static arrays in Theme.cpp.  Then maybe the
> >>>> linker
> >>>> puts those tables somewhere else, and the subtle bug in macOs, if that's
> >>>> what it is, will be averted.
> >>>>
> >>>> If that does fix it I would be worried!  It shows something unknown
> >>> going
> >>> on.
> >>> Definitely worth trying.   If it does fix it, we should look at other
> >>> things after doing that to try to narrow down the root cause.
> >>>
> >>> Maybe though we might need a more difficult fix involving memory mapped
> >>>
> >>>> files, and bundling these compressed images as resources.
> >>>>
> >>>> I don't think that would be good if we are still uncertain about the
> >>> root
> >>> cause.
> >>>
> >>> --James.
> >>>
> >>
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

James Crook
In reply to this post by Paul Licameli
On 7/26/2017 5:42 PM, Paul Licameli wrote:

> On Wed, Jul 26, 2017 at 12:24 PM, Paul Licameli <[hidden email]>
> wrote:
>
>>
>> On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:
>>
>>> On 7/26/2017 4:47 PM, Paul Licameli wrote:
>>>
>>>> On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:
>>>>
>>>> On 7/26/2017 3:09 PM, Paul Licameli wrote:
>>>>> On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
>>>>>> Cliff, Peter and Bill narrowed down a Mac crash error to a particular
>>>>>>
>>>>>>> commit by me:
>>>>>>>
>>>>>>> This is the crash.  Only on machines without the library, not on
>>>>>>> developer
>>>>>>> machines:
>>>>>>>
>>>>>>> Starting Variant B with CFG set to Classic Theme gives this crash
>>>>>>>
>>>>>>> Dyld Error Message:
>>>>>>>>       Library not loaded: /usr/local/lib/libwx_osx_cocoa
>>>>>>>> u_release_core-3.0.dylib
>>>>>>>>       Referenced from: /Applications/Audacity 220 July 23
>>>>>>>> B/Audacity.app/Contents/MacOS/Audacity
>>>>>>>>       Reason: image not found
>>>>>>>>
>>>>>>>> And the commit that triggers it is:
>>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
>>>>>>> 64849791f72a742081285574
>>>>>>>
>>>>>>> This is totally mysterious to me.  The change is 'only' to a
>>>>>>> compressed
>>>>>>> bitmap stored as numbers embedded in the executable. There is no way
>>>>>>> it
>>>>>>> should be changing which libraries get loaded. In order to narrow the
>>>>>>> issue
>>>>>>> down, I have reverted the change with this commit:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/c316f8122b188cc7
>>>>>>> 8c703f3261de2d683383d635
>>>>>>>
>>>>>>> The theme will now have a rather too grey background.  Hopefully it
>>>>>>> 'fixes' the issue on Mac, and we can then investigate further changes
>>>>>>> that
>>>>>>> may tell us what the real problem is.
>>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>> I did not follow in detail.  Do I understand that there is good
>>>>>>> evidence
>>>>>>>
>>>>>> for this bisection, consistent crashes in one build and not another,
>>>>>> provided that preferences choose Light theme?
>>>>>>
>>>>>> I think the evidence is weakish.  The build crashes are consistent -
>>>>> the
>>>>> build before is OK, the build itself and those tried after crash.
>>>>> That's
>>>>> consistent, but is not dependent on what theme is selected.
>>>>>
>>>>> So I understand bisection clearly implicates a commit in which only the
>>>> theme data changed?
>>>>
>>> That and the recent 'fix' (your idea of not using the const) does now.
>>>
>>> But remind me why we thought the configuration file had any influence on
>>>> the bug?
>>>>
>>> I thought the way that that (exact) data could cause a problem via memory
>>> corruption would be if wxMemoryInputStream was the villain,
>>
>> You mean you peeked inside that class, as I did, and saw a suspicious
>> const_cast in the constructor, and wondered if a wxW bug writes to
>> read-only data?  But I did not go deeply enough to confirm such a suspicion.
>>
>>
>>> and the data tickled its bug.  BUT that could only happen if the Light
>>> Theme and its data were used.  Since the crash happened when config file
>>> had Dark theme set, that ruled out processing of the data as being the
>>> problem.  It's its existence that is the issue.
>>>
>>> Which seems really bizarre, because I think the loading of the dynamic
>>>> libraries happens very early in the process, before we come near any code
>>>> that uses the theme data arrays.  How could this influence what happens
>>>> earlier in the process?
>>>>
>>> You're right, and that's another reason pointing to it being the data
>>> itself that is the problem.  I had in mind delayed loading of dlls, e.g. if
>>> loaded only when needed.  But wxWidgets modules are loaded early.
>>>
>> I should have recalled it sooner:  Audacity does do something weird at
>> startup.  Remember how it uses fork and exec.  And it did that even before
>> we wrote our partial fixes for Bug 1567.
>>
>> Relevant old commits with fork and execve:
>> a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
>> [9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving
>> functions around I think]
>> [b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
>> 36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork
>>
>> That earliest was for fixing bug 543 http://bugzilla.
>> audacityteam.org/show_bug.cgi?id=543  See especially Comment 1 there.
>> Hmmmm....
>>
>> PRL
>>
> So what if we tried a build, in which you don't remove const, but you do
> skip the fork and execve?
And skip    unsetenv("DYLD_LIBRARY_PATH"); ?

> If that still crashes, we might eliminate the execve as the suspect.
Surely it's more likely to be the messing with the paths?

> If it doesn't, then maybe execve is part of the cause.  Or still maybe not,
> maybe the little disturbance to the executable image size or contents is
> what influences it.
>
> If exeve is possibly the cause, I don't have an idea what to do about it.
> That fork fix was decided to be very necessary to mitigate bug 1567 as much
> as we can, and that bug was something holding up the previous release.  We
> need it.
The current HEAD 'works', so worst case we could stay without the consts.

unsetenv("DYLD_LIBRARY_PATH"); could be causing our Bug 1567 problems
with gatekeeper.  E.g if Gatekeeper adds randomized paths to
"DYLD_LIBRARY_PATH" as part of its method of protecting.

If we've no better ideas after trying what you suggest, I'd like us to
try re-introducing the consts one at a time, and see if we can narrow
down what aspect of the consts causes the issue.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli
In reply to this post by Henric Jungheim


On Wed, Jul 26, 2017 at 12:48 PM, Henric Jungheim <[hidden email]> wrote:
On Wed, Jul 26, 2017 at 12:24:03PM -0400, Paul Licameli wrote:
> On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:
>
> > On 7/26/2017 4:47 PM, Paul Licameli wrote:
> >
> >> On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:
> >>
> >> On 7/26/2017 3:09 PM, Paul Licameli wrote:
> >>>
> >>> On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
> >>>>
> >>>> Cliff, Peter and Bill narrowed down a Mac crash error to a particular
> >>>>
> >>>>> commit by me:
> >>>>>
> >>>>> This is the crash.  Only on machines without the library, not on
> >>>>> developer
> >>>>> machines:
> >>>>>
> >>>>> Starting Variant B with CFG set to Classic Theme gives this crash
> >>>>>
> >>>>> Dyld Error Message:
> >>>>>>      Library not loaded: /usr/local/lib/libwx_osx_cocoa
> >>>>>> u_release_core-3.0.dylib
> >>>>>>      Referenced from: /Applications/Audacity 220 July 23
> >>>>>> B/Audacity.app/Contents/MacOS/Audacity
> >>>>>>      Reason: image not found
> >>>>>>
> >>>>>> And the commit that triggers it is:
> >>>>>>
> >>>>> https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
> >>>>> 64849791f72a742081285574
> >>>>>
> >>>>> This is totally mysterious to me.  The change is 'only' to a compressed
> >>>>> bitmap stored as numbers embedded in the executable. There is no way it
> >>>>> should be changing which libraries get loaded. In order to narrow the
> >>>>> issue
> >>>>> down, I have reverted the change with this commit:
> >>>>>
> >>>>> https://github.com/audacity/audacity/commit/c316f8122b188cc7
> >>>>> 8c703f3261de2d683383d635
> >>>>>
> >>>>> The theme will now have a rather too grey background.  Hopefully it
> >>>>> 'fixes' the issue on Mac, and we can then investigate further changes
> >>>>> that
> >>>>> may tell us what the real problem is.
> >>>>>
> >>>>> --James.
> >>>>>
> >>>>> I did not follow in detail.  Do I understand that there is good
> >>>>> evidence
> >>>>>
> >>>> for this bisection, consistent crashes in one build and not another,
> >>>> provided that preferences choose Light theme?
> >>>>
> >>>> I think the evidence is weakish.  The build crashes are consistent - the
> >>> build before is OK, the build itself and those tried after crash.  That's
> >>> consistent, but is not dependent on what theme is selected.
> >>>
> >>> So I understand bisection clearly implicates a commit in which only the
> >> theme data changed?
> >>
> > That and the recent 'fix' (your idea of not using the const) does now.
> >
> > But remind me why we thought the configuration file had any influence on
> >> the bug?
> >>
> > I thought the way that that (exact) data could cause a problem via memory
> > corruption would be if wxMemoryInputStream was the villain,
>
>
> You mean you peeked inside that class, as I did, and saw a suspicious
> const_cast in the constructor, and wondered if a wxW bug writes to
> read-only data?  But I did not go deeply enough to confirm such a suspicion.

A write to data in a read-only section should be obvious;
there should be a segfault.

That's what I thought too, so I didn't really believe that hypothesis.
 
Does the Mac Audacity try to
catch such things (for error reporting or what-not)?

Does running Audacity under "dtruss -f" show anything odd?

Oh wow, I didn't know dtruss, and I wish we had used it to gather data when working on bug 1567.  It may yet be useful.

But when I run the Audacity program in dtruss, it fails in ways that don't happen otherwise.  Something about the temp directory.

PRL

 

This should distinguish between the section layout and if
the "const"ness itself is causing a problem: Keep the data
const, but copy it to a writable memory buffer before
passing it to wxMemoryInputStream.  If it is something to do
with the layout, then "static const ABunchOfConstData[5 *
1024 * 1024] = { 1 };" would presumable be enough to cause
grief (assuming the linker isn't clever enough to eliminate
unreferenced data). 

>
>
> > and the data tickled its bug.  BUT that could only happen if the Light
> > Theme and its data were used.  Since the crash happened when config file
> > had Dark theme set, that ruled out processing of the data as being the
> > problem.  It's its existence that is the issue.
> >
> > Which seems really bizarre, because I think the loading of the dynamic
> >> libraries happens very early in the process, before we come near any code
> >> that uses the theme data arrays.  How could this influence what happens
> >> earlier in the process?
> >>
> > You're right, and that's another reason pointing to it being the data
> > itself that is the problem.  I had in mind delayed loading of dlls, e.g. if
> > loaded only when needed.  But wxWidgets modules are loaded early.
> >
>
> I should have recalled it sooner:  Audacity does do something weird at
> startup.  Remember how it uses fork and exec.  And it did that even before
> we wrote our partial fixes for Bug 1567.
>
> Relevant old commits with fork and execve:
> a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
> [9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving functions
> around I think]
> [b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
> 36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork
>
> That earliest was for fixing bug 543
> http://bugzilla.audacityteam.org/show_bug.cgi?id=543  See especially
> Comment 1 there.  Hmmmm....
>
> PRL
>
>
>
>
> >
> > It doesn't seem to be that we have too much const data.
> > Perhaps there is a certain size and positioning that causes some issue.
> > Perhaps there is something to do with paths that is being messed up.  It
> > might even be another symptom of http://bugzilla.audacityteam.o
> > rg/show_bug.cgi?id=1567 if something is messing with search paths.
> >
> > --James.
> >
> > Unless, good grief, somehow the previous run of the program influences the
> >> occurrence of the bug in the next?
> >>
> > No evidence for that yet.  My impression from the reports is that the
> > builds run OK or crash 'reliably'.
> >
> >
> > Or is configuration setting a red herring?
> >>
> > A red herring.  A hypothesis refuted by Bill's Dark theme results.
> >
> >> Is there intermittent non-occurrence of it because of who knows what
> >> subtleties in the operating system?
> >>
> > No evidence (yet) of intermittent non-occurence for the same build.
> >
> > --James.
> >
> >
> >
> >
> >> PRL
> >>
> >>
> >>
> >> If builds of current head which has reverted data don't crash, then that
> >>> is reasonably strong evidence that the data is causing the issue.
> >>>
> >>>
> >>> And here is a wild guess for a simple fix of it.  Remove "const" from the
> >>>
> >>>> declarations of the four static arrays in Theme.cpp.  Then maybe the
> >>>> linker
> >>>> puts those tables somewhere else, and the subtle bug in macOs, if that's
> >>>> what it is, will be averted.
> >>>>
> >>>> If that does fix it I would be worried!  It shows something unknown
> >>> going
> >>> on.
> >>> Definitely worth trying.   If it does fix it, we should look at other
> >>> things after doing that to try to narrow down the root cause.
> >>>
> >>> Maybe though we might need a more difficult fix involving memory mapped
> >>>
> >>>> files, and bundling these compressed images as resources.
> >>>>
> >>>> I don't think that would be good if we are still uncertain about the
> >>> root
> >>> cause.
> >>>
> >>> --James.
> >>>
> >>
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli
In reply to this post by James Crook


On Wed, Jul 26, 2017 at 1:10 PM, James Crook <[hidden email]> wrote:
On 7/26/2017 5:42 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 12:24 PM, Paul Licameli <[hidden email]>
wrote:


On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:

On 7/26/2017 4:47 PM, Paul Licameli wrote:

On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:

On 7/26/2017 3:09 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
Cliff, Peter and Bill narrowed down a Mac crash error to a particular

commit by me:

This is the crash.  Only on machines without the library, not on
developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash

Dyld Error Message:
      Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
      Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
      Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a
compressed
bitmap stored as numbers embedded in the executable. There is no way
it
should be changing which libraries get loaded. In order to narrow the
issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes
that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good
evidence

for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?

I think the evidence is weakish.  The build crashes are consistent -
the
build before is OK, the build itself and those tried after crash.
That's
consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the
theme data changed?

That and the recent 'fix' (your idea of not using the const) does now.

But remind me why we thought the configuration file had any influence on
the bug?

I thought the way that that (exact) data could cause a problem via memory
corruption would be if wxMemoryInputStream was the villain,

You mean you peeked inside that class, as I did, and saw a suspicious
const_cast in the constructor, and wondered if a wxW bug writes to
read-only data?  But I did not go deeply enough to confirm such a suspicion.


and the data tickled its bug.  BUT that could only happen if the Light
Theme and its data were used.  Since the crash happened when config file
had Dark theme set, that ruled out processing of the data as being the
problem.  It's its existence that is the issue.

Which seems really bizarre, because I think the loading of the dynamic
libraries happens very early in the process, before we come near any code
that uses the theme data arrays.  How could this influence what happens
earlier in the process?

You're right, and that's another reason pointing to it being the data
itself that is the problem.  I had in mind delayed loading of dlls, e.g. if
loaded only when needed.  But wxWidgets modules are loaded early.

I should have recalled it sooner:  Audacity does do something weird at
startup.  Remember how it uses fork and exec.  And it did that even before
we wrote our partial fixes for Bug 1567.

Relevant old commits with fork and execve:
a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
[9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving
functions around I think]
[b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork

That earliest was for fixing bug 543 http://bugzilla.
audacityteam.org/show_bug.cgi?id=543  See especially Comment 1 there.
Hmmmm....

PRL

So what if we tried a build, in which you don't remove const, but you do
skip the fork and execve?
And skip    unsetenv("DYLD_LIBRARY_PATH"); ?

Well you can skip that too, but my understanding is that this environment variable influences the loading of the libraries, which has happened already even before our main() is reached.  (That, I think, is why Leland used execve in the first place.  You have to change the environment, then execve to go through the loading of libraries again.)

So that is, I think that if for present experimental purposes you don't do execve, then it should not matter whether the unsetenv is done or not.

And now this makes me wonder if there is a way to make a separate tiny launcher program for Audacity, which does that environment variable change and then exec the big program.  If the little program never loads the wxw libraries before changing the environment and doing exec, does that evade whatever layout-moonphase problem this is?  Why wasn't Bug 543 fixed like that?  I must research the history.  Maybe it was the lazy way to write the fix, not defining a second executable program, or maybe there was some other reason.

And would that have been the right way to solve the griefs of 1567 too?  Without that bizarre fork and crash?



If that still crashes, we might eliminate the execve as the suspect.
Surely it's more likely to be the messing with the paths?

If it doesn't, then maybe execve is part of the cause.  Or still maybe not,
maybe the little disturbance to the executable image size or contents is
what influences it.

If exeve is possibly the cause, I don't have an idea what to do about it.
That fork fix was decided to be very necessary to mitigate bug 1567 as much
as we can, and that bug was something holding up the previous release.  We
need it.
The current HEAD 'works', so worst case we could stay without the consts.

unsetenv("DYLD_LIBRARY_PATH"); could be causing our Bug 1567 problems with gatekeeper.  E.g if Gatekeeper adds randomized paths to "DYLD_LIBRARY_PATH" as part of its method of protecting.

If we've no better ideas after trying what you suggest, I'd like us to try re-introducing the consts one at a time, and see if we can narrow down what aspect of the consts causes the issue.


Why do we do all of this crazy stuff anyway?

The symptom in bug 543 -- it was reported in macOS 10.8, and was the reason we added the suspicious execve and unsetenv.  That was a bug Leland traced to library loading, which was also the topic of 1567 and this unnumbered bug.

Did the fix for 543 cause the bug 1567?
Did it, or did the partial workaround fix for 1567, cause the present problem?
Would undoing the partial fix for 1567, and also that for 543, cure the symptoms of 1567?
If so, do we reopen the P4 bug 543 and live with its symptoms?
Would the symptoms of 543 not happen anyway in later macOS versions?

These are difficult quesions to answer, especially as we were relying on Gale for data about 1567 which I think never affected anybody else on the Team though there were some reports on the forum.

PRL

 

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Bill Wharrie
Sorry if I’m talking above my pay grade here, but who cares about bug 543 any more? It was obscure to start with (application “Kind” not reported properly in the System Information application). “Universal” apps are no more, and in 10.11.4, System Information reports “Kind” as “Intel” for all apps (AFAICT). And “Get Info” on any app reports “Kind” as “Application”.
— Bill

On 2017/07/26, at 1:42 PM, Paul Licameli <[hidden email]> wrote:



On Wed, Jul 26, 2017 at 1:10 PM, James Crook <[hidden email]> wrote:
On 7/26/2017 5:42 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 12:24 PM, Paul Licameli <[hidden email]>
wrote:


On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:

On 7/26/2017 4:47 PM, Paul Licameli wrote:

On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:

On 7/26/2017 3:09 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
Cliff, Peter and Bill narrowed down a Mac crash error to a particular

commit by me:

This is the crash.  Only on machines without the library, not on
developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash

Dyld Error Message:
      Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
      Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
      Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a
compressed
bitmap stored as numbers embedded in the executable. There is no way
it
should be changing which libraries get loaded. In order to narrow the
issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes
that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good
evidence

for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?

I think the evidence is weakish.  The build crashes are consistent -
the
build before is OK, the build itself and those tried after crash.
That's
consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the
theme data changed?

That and the recent 'fix' (your idea of not using the const) does now.

But remind me why we thought the configuration file had any influence on
the bug?

I thought the way that that (exact) data could cause a problem via memory
corruption would be if wxMemoryInputStream was the villain,

You mean you peeked inside that class, as I did, and saw a suspicious
const_cast in the constructor, and wondered if a wxW bug writes to
read-only data?  But I did not go deeply enough to confirm such a suspicion.


and the data tickled its bug.  BUT that could only happen if the Light
Theme and its data were used.  Since the crash happened when config file
had Dark theme set, that ruled out processing of the data as being the
problem.  It's its existence that is the issue.

Which seems really bizarre, because I think the loading of the dynamic
libraries happens very early in the process, before we come near any code
that uses the theme data arrays.  How could this influence what happens
earlier in the process?

You're right, and that's another reason pointing to it being the data
itself that is the problem.  I had in mind delayed loading of dlls, e.g. if
loaded only when needed.  But wxWidgets modules are loaded early.

I should have recalled it sooner:  Audacity does do something weird at
startup.  Remember how it uses fork and exec.  And it did that even before
we wrote our partial fixes for Bug 1567.

Relevant old commits with fork and execve:
a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
[9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving
functions around I think]
[b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork

That earliest was for fixing bug 543 http://bugzilla.
audacityteam.org/show_bug.cgi?id=543  See especially Comment 1 there.
Hmmmm....

PRL

So what if we tried a build, in which you don't remove const, but you do
skip the fork and execve?
And skip    unsetenv("DYLD_LIBRARY_PATH"); ?

Well you can skip that too, but my understanding is that this environment variable influences the loading of the libraries, which has happened already even before our main() is reached.  (That, I think, is why Leland used execve in the first place.  You have to change the environment, then execve to go through the loading of libraries again.)

So that is, I think that if for present experimental purposes you don't do execve, then it should not matter whether the unsetenv is done or not.

And now this makes me wonder if there is a way to make a separate tiny launcher program for Audacity, which does that environment variable change and then exec the big program.  If the little program never loads the wxw libraries before changing the environment and doing exec, does that evade whatever layout-moonphase problem this is?  Why wasn't Bug 543 fixed like that?  I must research the history.  Maybe it was the lazy way to write the fix, not defining a second executable program, or maybe there was some other reason.

And would that have been the right way to solve the griefs of 1567 too?  Without that bizarre fork and crash?



If that still crashes, we might eliminate the execve as the suspect.
Surely it's more likely to be the messing with the paths?

If it doesn't, then maybe execve is part of the cause.  Or still maybe not,
maybe the little disturbance to the executable image size or contents is
what influences it.

If exeve is possibly the cause, I don't have an idea what to do about it.
That fork fix was decided to be very necessary to mitigate bug 1567 as much
as we can, and that bug was something holding up the previous release.  We
need it.
The current HEAD 'works', so worst case we could stay without the consts.

unsetenv("DYLD_LIBRARY_PATH"); could be causing our Bug 1567 problems with gatekeeper.  E.g if Gatekeeper adds randomized paths to "DYLD_LIBRARY_PATH" as part of its method of protecting.

If we've no better ideas after trying what you suggest, I'd like us to try re-introducing the consts one at a time, and see if we can narrow down what aspect of the consts causes the issue.


Why do we do all of this crazy stuff anyway?

The symptom in bug 543 -- it was reported in macOS 10.8, and was the reason we added the suspicious execve and unsetenv.  That was a bug Leland traced to library loading, which was also the topic of 1567 and this unnumbered bug.

Did the fix for 543 cause the bug 1567?
Did it, or did the partial workaround fix for 1567, cause the present problem?
Would undoing the partial fix for 1567, and also that for 543, cure the symptoms of 1567?
If so, do we reopen the P4 bug 543 and live with its symptoms?
Would the symptoms of 543 not happen anyway in later macOS versions?

These are difficult quesions to answer, especially as we were relying on Gale for data about 1567 which I think never affected anybody else on the Team though there were some reports on the forum.

PRL

 

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli


On Wed, Jul 26, 2017 at 2:42 PM, Bill Wharrie <[hidden email]> wrote:
Sorry if I’m talking above my pay grade here, but who cares about bug 543 any more? It was obscure to start with (application “Kind” not reported properly in the System Information application). “Universal” apps are no more, and in 10.11.4, System Information reports “Kind” as “Intel” for all apps (AFAICT). And “Get Info” on any app reports “Kind” as “Application”.
— Bill

Why was it important to fix to begin with?  Gale commented "Reported several times a year."  But were these reports really complaints?

If I understand Leland's comment 1, then what I suggested, a little program changing environment first and then starting Audacity, is in fact what used to happen, but the little program was a script, and that explained the bug symptoms.

But again I don't understand why this changing of environment, whether by a script or by doing execve, is needed.  Something about really loading the FFmpeg and LAME libraries from the places you specify in preferences.  I will try to understand some of the code history.  Maybe someone with longer experience can explain what that's all about.

Meanwhile there is also "man dyld" in my queue of light reading.

PRL

 

On 2017/07/26, at 1:42 PM, Paul Licameli <[hidden email]> wrote:



On Wed, Jul 26, 2017 at 1:10 PM, James Crook <[hidden email]> wrote:
On 7/26/2017 5:42 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 12:24 PM, Paul Licameli <[hidden email]>
wrote:


On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:

On 7/26/2017 4:47 PM, Paul Licameli wrote:

On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:

On 7/26/2017 3:09 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
Cliff, Peter and Bill narrowed down a Mac crash error to a particular

commit by me:

This is the crash.  Only on machines without the library, not on
developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash

Dyld Error Message:
      Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
      Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
      Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a
compressed
bitmap stored as numbers embedded in the executable. There is no way
it
should be changing which libraries get loaded. In order to narrow the
issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes
that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good
evidence

for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?

I think the evidence is weakish.  The build crashes are consistent -
the
build before is OK, the build itself and those tried after crash.
That's
consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the
theme data changed?

That and the recent 'fix' (your idea of not using the const) does now.

But remind me why we thought the configuration file had any influence on
the bug?

I thought the way that that (exact) data could cause a problem via memory
corruption would be if wxMemoryInputStream was the villain,

You mean you peeked inside that class, as I did, and saw a suspicious
const_cast in the constructor, and wondered if a wxW bug writes to
read-only data?  But I did not go deeply enough to confirm such a suspicion.


and the data tickled its bug.  BUT that could only happen if the Light
Theme and its data were used.  Since the crash happened when config file
had Dark theme set, that ruled out processing of the data as being the
problem.  It's its existence that is the issue.

Which seems really bizarre, because I think the loading of the dynamic
libraries happens very early in the process, before we come near any code
that uses the theme data arrays.  How could this influence what happens
earlier in the process?

You're right, and that's another reason pointing to it being the data
itself that is the problem.  I had in mind delayed loading of dlls, e.g. if
loaded only when needed.  But wxWidgets modules are loaded early.

I should have recalled it sooner:  Audacity does do something weird at
startup.  Remember how it uses fork and exec.  And it did that even before
we wrote our partial fixes for Bug 1567.

Relevant old commits with fork and execve:
a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
[9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving
functions around I think]
[b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork

That earliest was for fixing bug 543 http://bugzilla.
audacityteam.org/show_bug.cgi?id=543  See especially Comment 1 there.
Hmmmm....

PRL

So what if we tried a build, in which you don't remove const, but you do
skip the fork and execve?
And skip    unsetenv("DYLD_LIBRARY_PATH"); ?

Well you can skip that too, but my understanding is that this environment variable influences the loading of the libraries, which has happened already even before our main() is reached.  (That, I think, is why Leland used execve in the first place.  You have to change the environment, then execve to go through the loading of libraries again.)

So that is, I think that if for present experimental purposes you don't do execve, then it should not matter whether the unsetenv is done or not.

And now this makes me wonder if there is a way to make a separate tiny launcher program for Audacity, which does that environment variable change and then exec the big program.  If the little program never loads the wxw libraries before changing the environment and doing exec, does that evade whatever layout-moonphase problem this is?  Why wasn't Bug 543 fixed like that?  I must research the history.  Maybe it was the lazy way to write the fix, not defining a second executable program, or maybe there was some other reason.

And would that have been the right way to solve the griefs of 1567 too?  Without that bizarre fork and crash?



If that still crashes, we might eliminate the execve as the suspect.
Surely it's more likely to be the messing with the paths?

If it doesn't, then maybe execve is part of the cause.  Or still maybe not,
maybe the little disturbance to the executable image size or contents is
what influences it.

If exeve is possibly the cause, I don't have an idea what to do about it.
That fork fix was decided to be very necessary to mitigate bug 1567 as much
as we can, and that bug was something holding up the previous release.  We
need it.
The current HEAD 'works', so worst case we could stay without the consts.

unsetenv("DYLD_LIBRARY_PATH"); could be causing our Bug 1567 problems with gatekeeper.  E.g if Gatekeeper adds randomized paths to "DYLD_LIBRARY_PATH" as part of its method of protecting.

If we've no better ideas after trying what you suggest, I'd like us to try re-introducing the consts one at a time, and see if we can narrow down what aspect of the consts causes the issue.


Why do we do all of this crazy stuff anyway?

The symptom in bug 543 -- it was reported in macOS 10.8, and was the reason we added the suspicious execve and unsetenv.  That was a bug Leland traced to library loading, which was also the topic of 1567 and this unnumbered bug.

Did the fix for 543 cause the bug 1567?
Did it, or did the partial workaround fix for 1567, cause the present problem?
Would undoing the partial fix for 1567, and also that for 543, cure the symptoms of 1567?
If so, do we reopen the P4 bug 543 and live with its symptoms?
Would the symptoms of 543 not happen anyway in later macOS versions?

These are difficult quesions to answer, especially as we were relying on Gale for data about 1567 which I think never affected anybody else on the Team though there were some reports on the forum.

PRL

 

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mac: 3.0.dylib error.

Paul Licameli


On Wed, Jul 26, 2017 at 2:52 PM, Paul Licameli <[hidden email]> wrote:


On Wed, Jul 26, 2017 at 2:42 PM, Bill Wharrie <[hidden email]> wrote:
Sorry if I’m talking above my pay grade here, but who cares about bug 543 any more? It was obscure to start with (application “Kind” not reported properly in the System Information application). “Universal” apps are no more, and in 10.11.4, System Information reports “Kind” as “Intel” for all apps (AFAICT). And “Get Info” on any app reports “Kind” as “Application”.
— Bill

Why was it important to fix to begin with?  Gale commented "Reported several times a year."  But were these reports really complaints?

If I understand Leland's comment 1, then what I suggested, a little program changing environment first and then starting Audacity, is in fact what used to happen, but the little program was a script, and that explained the bug symptoms.

But again I don't understand why this changing of environment, whether by a script or by doing execve, is needed.  Something about really loading the FFmpeg and LAME libraries from the places you specify in preferences.  I will try to understand some of the code history.  Maybe someone with longer experience can explain what that's all about.

Meanwhile there is also "man dyld" in my queue of light reading.

PRL


I have opened a new P2 bug, 1702, for this, and added you and others to the CC list.

I dug some more into git and buzilla history today.

I will soon summarize that in a comment at http://bugzilla.audacityteam.org/show_bug.cgi?id=1702 and we can resume the discussion there.

PRL

 
 

On 2017/07/26, at 1:42 PM, Paul Licameli <[hidden email]> wrote:



On Wed, Jul 26, 2017 at 1:10 PM, James Crook <[hidden email]> wrote:
On 7/26/2017 5:42 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 12:24 PM, Paul Licameli <[hidden email]>
wrote:


On Wed, Jul 26, 2017 at 12:06 PM, James Crook <[hidden email]> wrote:

On 7/26/2017 4:47 PM, Paul Licameli wrote:

On Wed, Jul 26, 2017 at 10:23 AM, James Crook <[hidden email]> wrote:

On 7/26/2017 3:09 PM, Paul Licameli wrote:
On Wed, Jul 26, 2017 at 7:09 AM, James Crook <[hidden email]> wrote:
Cliff, Peter and Bill narrowed down a Mac crash error to a particular

commit by me:

This is the crash.  Only on machines without the library, not on
developer
machines:

Starting Variant B with CFG set to Classic Theme gives this crash

Dyld Error Message:
      Library not loaded: /usr/local/lib/libwx_osx_cocoa
u_release_core-3.0.dylib
      Referenced from: /Applications/Audacity 220 July 23
B/Audacity.app/Contents/MacOS/Audacity
      Reason: image not found

And the commit that triggers it is:

https://github.com/audacity/audacity/commit/a8ba5d567ed3ffe7
64849791f72a742081285574

This is totally mysterious to me.  The change is 'only' to a
compressed
bitmap stored as numbers embedded in the executable. There is no way
it
should be changing which libraries get loaded. In order to narrow the
issue
down, I have reverted the change with this commit:

https://github.com/audacity/audacity/commit/c316f8122b188cc7
8c703f3261de2d683383d635

The theme will now have a rather too grey background.  Hopefully it
'fixes' the issue on Mac, and we can then investigate further changes
that
may tell us what the real problem is.

--James.

I did not follow in detail.  Do I understand that there is good
evidence

for this bisection, consistent crashes in one build and not another,
provided that preferences choose Light theme?

I think the evidence is weakish.  The build crashes are consistent -
the
build before is OK, the build itself and those tried after crash.
That's
consistent, but is not dependent on what theme is selected.

So I understand bisection clearly implicates a commit in which only the
theme data changed?

That and the recent 'fix' (your idea of not using the const) does now.

But remind me why we thought the configuration file had any influence on
the bug?

I thought the way that that (exact) data could cause a problem via memory
corruption would be if wxMemoryInputStream was the villain,

You mean you peeked inside that class, as I did, and saw a suspicious
const_cast in the constructor, and wondered if a wxW bug writes to
read-only data?  But I did not go deeply enough to confirm such a suspicion.


and the data tickled its bug.  BUT that could only happen if the Light
Theme and its data were used.  Since the crash happened when config file
had Dark theme set, that ruled out processing of the data as being the
problem.  It's its existence that is the issue.

Which seems really bizarre, because I think the loading of the dynamic
libraries happens very early in the process, before we come near any code
that uses the theme data arrays.  How could this influence what happens
earlier in the process?

You're right, and that's another reason pointing to it being the data
itself that is the problem.  I had in mind delayed loading of dlls, e.g. if
loaded only when needed.  But wxWidgets modules are loaded early.

I should have recalled it sooner:  Audacity does do something weird at
startup.  Remember how it uses fork and exec.  And it did that even before
we wrote our partial fixes for Bug 1567.

Relevant old commits with fork and execve:
a05d039055909d7d1dc2d4f31e1fe0659a3207dd me, introduced the fork
[9b9c8cc07365058e2e321df14d6d4bde31a90b83 Leland but just moving
functions around I think]
[b7d6af1d87d34952c044f5be8ceb4ac61625fc92 James but ditto]
36361a6b86dac4b0f2b16b7017007b4cc7717c7a Leland, exeve but not fork

That earliest was for fixing bug 543 http://bugzilla.
audacityteam.org/show_bug.cgi?id=543  See especially Comment 1 there.
Hmmmm....

PRL

So what if we tried a build, in which you don't remove const, but you do
skip the fork and execve?
And skip    unsetenv("DYLD_LIBRARY_PATH"); ?

Well you can skip that too, but my understanding is that this environment variable influences the loading of the libraries, which has happened already even before our main() is reached.  (That, I think, is why Leland used execve in the first place.  You have to change the environment, then execve to go through the loading of libraries again.)

So that is, I think that if for present experimental purposes you don't do execve, then it should not matter whether the unsetenv is done or not.

And now this makes me wonder if there is a way to make a separate tiny launcher program for Audacity, which does that environment variable change and then exec the big program.  If the little program never loads the wxw libraries before changing the environment and doing exec, does that evade whatever layout-moonphase problem this is?  Why wasn't Bug 543 fixed like that?  I must research the history.  Maybe it was the lazy way to write the fix, not defining a second executable program, or maybe there was some other reason.

And would that have been the right way to solve the griefs of 1567 too?  Without that bizarre fork and crash?



If that still crashes, we might eliminate the execve as the suspect.
Surely it's more likely to be the messing with the paths?

If it doesn't, then maybe execve is part of the cause.  Or still maybe not,
maybe the little disturbance to the executable image size or contents is
what influences it.

If exeve is possibly the cause, I don't have an idea what to do about it.
That fork fix was decided to be very necessary to mitigate bug 1567 as much
as we can, and that bug was something holding up the previous release.  We
need it.
The current HEAD 'works', so worst case we could stay without the consts.

unsetenv("DYLD_LIBRARY_PATH"); could be causing our Bug 1567 problems with gatekeeper.  E.g if Gatekeeper adds randomized paths to "DYLD_LIBRARY_PATH" as part of its method of protecting.

If we've no better ideas after trying what you suggest, I'd like us to try re-introducing the consts one at a time, and see if we can narrow down what aspect of the consts causes the issue.


Why do we do all of this crazy stuff anyway?

The symptom in bug 543 -- it was reported in macOS 10.8, and was the reason we added the suspicious execve and unsetenv.  That was a bug Leland traced to library loading, which was also the topic of 1567 and this unnumbered bug.

Did the fix for 543 cause the bug 1567?
Did it, or did the partial workaround fix for 1567, cause the present problem?
Would undoing the partial fix for 1567, and also that for 543, cure the symptoms of 1567?
If so, do we reopen the P4 bug 543 and live with its symptoms?
Would the symptoms of 543 not happen anyway in later macOS versions?

These are difficult quesions to answer, especially as we were relying on Gale for data about 1567 which I think never affected anybody else on the Team though there were some reports on the forum.

PRL

 

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
12
Loading...