On macOS 10.13, Scintilla launched from an SMB share freezes

[Chinh Nguyen]

This may be a bug in macOS 10.13 which is why I'm not filing a bug report with Scintilla but I thought I'd see if it's possible that there's an issue with how Scintilla's framework is packaged.

If your app containing the Scintilla framework is stored on an SMB server (Windows or Mac, doesn't matter) and you launch the app from the SMB share on macOS 10.13, attempting to open a Scintilla view will freeze your app. You can confirm this by launching the Scintilla Test app from an SMB server.

If the app is stored on an AFP server, there's no problem. If you run the app on macOS 10.12 from SMB or AFP, there's no problem.

I thought maybe there's a problem with macOS 10.13 loading frameworks across SMB (maybe an issue with symbolic links) but I copied Adobe Acrobat Reader and Skim which both contain frameworks to my SMB share and neither app had a problem. That's not to say that my testing was extensive or that I tested them properly by ensuring a framework was loaded but at least with Skim, it uses the Sparkle update framework and I did have it check for an update with no bad results.

Should I chalk this up to being a bug in macOS 10.13?

This is an issue for me because some of my users use my app from an SMB server that's managed by their IT department.

[Neil Hodgson]

Chinh Nguyen:

> If your app containing the Scintilla framework is stored on an SMB server (Windows or Mac, doesn't matter) and you launch the app from the SMB share on macOS 10.13, attempting to open a Scintilla view will freeze your app.

…

> I thought maybe there's a problem with macOS 10.13 loading frameworks across SMB (maybe an issue with symbolic links) but I copied Adobe Acrobat Reader and Skim which both contain frameworks to my SMB share and neither app had a problem.

Links were my guess too as frameworks are organized with links, Windows has different link functionality and SMB is based on Windows semantics. Its possible that the framework construction part of the Scintilla build is wrong - its fairly old.

Checking the resource loading in, for example ScintillaView+initialize may be worthwhile as that does explicit loading of framework files and could be sensitive to issues like 8.3 filenames or similar.

> That's not to say that my testing was extensive or that I tested them properly by ensuring a framework was loaded but at least with Skim, it uses the Sparkle update framework and I did have it check for an update with no bad results.

First check for warnings in Console.

Neil

[Chinh Nguyen]

Great tip and it helped me find the problem. For whatever reason, the InfoBar background image is failing to load ([bundle pathForResource:ofType:inDirectory:] is returning nil even though the bundle is valid). That may be the bug in macOS 10.13 with SMB. However, the reason Scintilla is freezing is because in the drawRect: method for the InfoBar, there's a while loop that endlessly loops because the background image doesn't exist. I changed the while loop to:

  while (mBackground.size.width != 0 && target.x < rect.origin.x + rect.size.width)

[Mike Lischke]

Great tip and it helped me find the problem. For whatever reason, the InfoBar background image is failing to load ([bundle pathForResource:ofType:inDirectory:] is returning nil even though the bundle is valid). That may be the bug in macOS 10.13 with SMB. However, the reason Scintilla is freezing is because in the drawRect: method for the InfoBar, there's a while loop that endlessly loops because the background image doesn't exist. I changed the while loop to:

  while (mBackground.size.width != 0 && target.x < rect.origin.x + rect.size.width)

Which shows no thought was given to protect this part of the code in case of failures. Who on earth wrote this code? Damn, it was me :-/ - mea culpa.

Better you check in advance if the image is valid and don't try to draw it all if not, instead of constantly doing a size check.

Mike
-- 
www.soft-gems.net

[Chinh Nguyen]

I thought about that but what if you somehow have an image of 0 width? Regardless, I don't think you need to tile the image because you can just scale it horizontally using drawInRect:.

Also, I added a fallback for pathForResource: failing:

  if (!path) {
    path = [bundle.bundlePath stringByAppendingPathComponent:@"Resources/info_bar_bg.tiff"];
  }

It's not pretty but it'll get around the bug in macOS 10.13.

[Chinh Nguyen]

On Tuesday, October 24, 2017 at 11:09:25 AM UTC-5, Mike Lischke wrote:

 

Better you check in advance if the image is valid and don't try to draw it all if not, instead of constantly doing a size check.

Mike
-- 
www.soft-gems.net

You're right, I missed what you meant the first time. 

[Neil Hodgson]

Chinh Nguyen:

> Also, I added a fallback for pathForResource: failing:
>
> if (!path) {
> path = [bundle.bundlePath stringByAppendingPathComponent:@"Resources/info_bar_bg.tiff"];
> }
>
> It's not pretty but it'll get around the bug in macOS 10.13.

There are similar issues with loading cursors, most noticeably, the reverse arrow isn’t displayed over the margins.

Neil