1. xcode@apple-dev.groups.io
  2. Messages
   Date   
Re: XCTests crashing user session back to login screen

Alex Zavatone
 

Hahaha. I love that note from the support page. Move Xcode and the Simulator to the trash?

Honestly, I also thought that it was impossible for an app to write outside of its memory space as of OSX. With what I was/am seeing, it is worrisome.

FYI, for Jens, there were no crash logs in user or system space for the loginWindow or whatever that process is called.

And even more FYI, the UITest session just did the same thing of crashing the user session back to the login screen on MacOS 10.4.6 and Xcode 10.2.1 just an hour ago.

On Oct 3, 2019, at 6:46 AM, Jeremy Hughes via Groups.Io <moon.rabbit=virginmedia.com@groups.io> wrote:

On 2 Oct 2019, at 16:47, Jens Alfke <jens@mooseyard.com> wrote:

Every time it happens, there are no logs that I can find explaining the cause. My suspicion is memory leaks in the iOS app I am testing and zombie pointers writing to memory outside of the simulator.
No, that hasn’t been possible since the OS 9 days. Every process is isolated in its own address space, and there should be no way for an application process to break other apps or your login session. What’s happening sounds like a crash of the top-level process of your login session (is it still called loginwindow?) or of the WindowServer.
Apple’s support page (https://support.apple.com/en-gb/HT200553) suggests that it is still possible for an application to bring down the system:

"If your Mac suspects that a particular app caused the restart, it might ask whether you would like to move the app to the Trash. Click Move to Trash, then contact the software developer to see if a software update is available.”

Jeremy
Re: XCTests crashing user session back to login screen

Jeremy Hughes
 

On 2 Oct 2019, at 16:47, Jens Alfke <jens@mooseyard.com> wrote:

Every time it happens, there are no logs that I can find explaining the cause. My suspicion is memory leaks in the iOS app I am testing and zombie pointers writing to memory outside of the simulator.
No, that hasn’t been possible since the OS 9 days. Every process is isolated in its own address space, and there should be no way for an application process to break other apps or your login session. What’s happening sounds like a crash of the top-level process of your login session (is it still called loginwindow?) or of the WindowServer.
Apple’s support page (https://support.apple.com/en-gb/HT200553) suggests that it is still possible for an application to bring down the system:

"If your Mac suspects that a particular app caused the restart, it might ask whether you would like to move the app to the Trash. Click Move to Trash, then contact the software developer to see if a software update is available.”

Jeremy
Re: XCTests crashing user session back to login screen

Alex Zavatone
 

What’s scary is that I have screenshots of my terminal session wondows getting corrupted and also safari menus turning into checkerboard patterns.

We had a metric shitton of zombie pointers that I mostly cleaned up, but it’s scary watching a 16 GB Mac either reboot or just kick the user back to the login screen while crashing out of the user session and with no logs at all.

On Oct 2, 2019, at 10:47 AM, Jens Alfke <jens@mooseyard.com> wrote:


On Oct 1, 2019, at 1:20 PM, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

Has anyone seen cases where running XCTests will crash the logged in user session out to the user login screen?
Yikes. File a bug report with Apple — that’s got to be a bug in a system framework or service.

Every time it happens, there are no logs that I can find explaining the cause. My suspicion is memory leaks in the iOS app I am testing and zombie pointers writing to memory outside of the simulator.
No, that hasn’t been possible since the OS 9 days. Every process is isolated in its own address space, and there should be no way for an application process to break other apps or your login session. What’s happening sounds like a crash of the top-level process of your login session (is it still called loginwindow?) or of the WindowServer.

—Jens
Re: Xcode 11 broke genstrings given *.mm

Gary L. Wade
 

Have you tried using the find command instead?
--
Gary L. Wade
http://www.garywade.com/

On Oct 2, 2019, at 11:03 AM, Chris Hanson <cmhanson@eschatologist.net> wrote:

On Oct 2, 2019, at 7:37 AM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote

But it's how genstrings works. It accepts multiple files. This works:

genstrings -q -o Base.lproj *.m *.h

This does not:

genstrings -q -o Base.lproj *.m *.mm

And neither does this:

genstrings -q -o Base.lproj *.mm
Tools on UNIX do not perform shell wildcard expansion themselves, the shell does that before the tool is ever called. genstrings is no different in that regard; to my knowledge it has never done shell expansion, and I can assure you that it does not perform shell expansion now.

Are there files matching the pattern *.mm in the directory in which you’re invoking genstrings? If not, some shells will pass the raw “*.mm” to genstrings, others will produce an error before invoking genstrings.

-- Chris

PS - Strings files should not be put into Base.lproj; an asset type that supports Base Internationalization has localized strings substituted into it at either build or runtime, like a xib or storyboard or Siri intent definition. Strings should always be in a concrete lproj.
Re: Xcode 11 broke genstrings given *.mm

Chris Hanson
 

On Oct 2, 2019, at 7:37 AM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote

But it's how genstrings works. It accepts multiple files. This works:

genstrings -q -o Base.lproj *.m *.h

This does not:

genstrings -q -o Base.lproj *.m *.mm

And neither does this:

genstrings -q -o Base.lproj *.mm
Tools on UNIX do not perform shell wildcard expansion themselves, the shell does that before the tool is ever called. genstrings is no different in that regard; to my knowledge it has never done shell expansion, and I can assure you that it does not perform shell expansion now.

Are there files matching the pattern *.mm in the directory in which you’re invoking genstrings? If not, some shells will pass the raw “*.mm” to genstrings, others will produce an error before invoking genstrings.

-- Chris

PS - Strings files should not be put into Base.lproj; an asset type that supports Base Internationalization has localized strings substituted into it at either build or runtime, like a xib or storyboard or Siri intent definition. Strings should always be in a concrete lproj.
Re: Xcode 11 broke genstrings given *.mm

Chris Hanson
 

On Oct 1, 2019, at 9:08 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

On Oct 1, 2019, at 20:50:44, Chris Hanson <cmhanson@eschatologist.net> wrote:

My suspicion is that you’re expecting “genstrings *.mm” to work in a directory that doesn’t contain any .mm files. The old genstrings would just silently ignore nonexistent files (e.g. a filename of literally “*.mm” as some shells will pass when expansion fails). Now it produces an error.
I expect my existing working scripts using "genstrings *.m *.mm" to work, since it would find at least one of those types in every source folder.
Nonetheless, somehow the string “*.mm” is being passed to genstrings. Since a file of that name does not exist, genstrings produces an error about that file rather than silently ignoring it.

Can you share the exact text of your script as well as the exact shell under which it’s being run?

-- Chris
Re: Xcode 11 broke genstrings given *.mm

Jonathan Prescott
 

genstrings itself does not expand filenames (turning *.mm into a.mm, b.mm, etc.). The shell does the expansion and feeds the file list to the command line and invokes genstrings with the expanded file list. If you "type

genstrings -q -o Base.lproj \*.m *.h

in a directory with .m and .h files, you will get the error with genstrings trying to open a "*.m" file. An interesting experiment would be to reverse the order of the .m and .mm specifications so that in a directory of with .m files, but, no .mm files, does genstrings process the .m files anyway while noting that there are no .mm files, i.e., does

genstrings -q -o Base.lproj *.mm *.m
exit 0

still process the .m files, even with genstrings complaining about no .mm files? Adding the “exit 0” keeps Xcode from complaining about a script file returning a non-zero status result.

You could also use something like:

for file in `ls -1 *.h *.m *.mm`
do
genstrings -q -o Base.lproj $file
done
exit 0

This will go through all the existing files with any of those suffixes. “ls" will complain about not finding files with a suffix in the error log, but it will process all the files it finds and send them to genstrings.

If you want to get one-liner about it

genstrings -q -o Base.lproj `ls *.h *.m *.mm`
exit 0

Jonathan

On Oct 2, 2019, at 10:37 AM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

On Oct 1, 2019, at 23:44:25, Marco S Hyman <marc@snafu.org> wrote:

On Oct 1, 2019, at 9:08 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

I expect my existing working scripts using "genstrings *.m *.mm" to work, since it would find at least one of those types in every source folder.
That’s not how shells work.
But it's how genstrings works. It accepts multiple files. This works:

genstrings -q -o Base.lproj *.m *.h

This does not:

genstrings -q -o Base.lproj *.m *.mm

And neither does this:

genstrings -q -o Base.lproj *.mm

--
Steve Mills
Drummer, Mac geek
Re: XCTests crashing user session back to login screen

Jens Alfke
 

On Oct 1, 2019, at 1:20 PM, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

Has anyone seen cases where running XCTests will crash the logged in user session out to the user login screen?
Yikes. File a bug report with Apple — that’s got to be a bug in a system framework or service.

Every time it happens, there are no logs that I can find explaining the cause. My suspicion is memory leaks in the iOS app I am testing and zombie pointers writing to memory outside of the simulator.
No, that hasn’t been possible since the OS 9 days. Every process is isolated in its own address space, and there should be no way for an application process to break other apps or your login session. What’s happening sounds like a crash of the top-level process of your login session (is it still called loginwindow?) or of the WindowServer.

—Jens
Re: Xcode 11 broke genstrings given *.mm

Steve Mills
 

On Oct 1, 2019, at 23:44:25, Marco S Hyman <marc@snafu.org> wrote:

On Oct 1, 2019, at 9:08 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

I expect my existing working scripts using "genstrings *.m *.mm" to work, since it would find at least one of those types in every source folder.
That’s not how shells work.
But it's how genstrings works. It accepts multiple files. This works:

genstrings -q -o Base.lproj *.m *.h

This does not:

genstrings -q -o Base.lproj *.m *.mm

And neither does this:

genstrings -q -o Base.lproj *.mm

--
Steve Mills
Drummer, Mac geek
Re: Xcode 11 broke my build when targeting an iPad

Steve Mills
 

Same totally useless error message happens when I build with 11.1 for an iOS device instead of Simulator:

Unable to find a profile type for platform iOS and purpose development. You may need to reinstall Xcode.

This is farking great. Just great.

--
Steve Mills
Drummer, Mac geek
Re: Xcode 11 broke my build when targeting an iPad

Steve Mills
 

On Oct 1, 2019, at 23:50:33, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

FYI,

https://old.reddit.com/r/swift/comments/dc4zx8/xcode_11_optimization_causing_random_crashes/
OK, but I'm not sure how that's relevant to the subject, other than an Xcode *.0 release being (typically) buggy as hell.

--
Steve Mills
Drummer, Mac geek
Re: Xcode 11 broke genstrings given *.mm

Bernie Maier
 

On Wed, 2 Oct 2019, at 4:42 PM, Jens Alfke wrote:
*.{m,mm} might work better.
As it happens, no. In both bash and zsh, whichever extension doesn’t match will still produce an error message. In both shells, brace expansion occurs before wildcard expansion and is basically a pure textual expansion without any check on the file system. Wildcard expansion does match against the file system.

zsh documentation (http://zsh.sourceforge.net/Doc/Release/Expansion.html#Brace-Expansion) says:

Note that brace expansion is not part of filename generation (globbing); an expression such as */{foo,bar} is split into two separate words */foo and */bar before filename generation takes place
bash documentation (https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html) says:

Brace expansion is performed before any other expansions, and any characters special to other expansions are preserved in the result. It is strictly textual.
In zsh you could do *.(m|mm) or even *.m(|m) if you wanted to be tricksy. There might be other obscure constructs.

Cheers,
Bernie

—Jens

On Oct 1, 2019, at 9:44 PM, Marco S Hyman <marc@snafu.org> wrote:



On Oct 1, 2019, at 9:08 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

I expect my existing working scripts using "genstrings *.m *.mm" to work, since it would find at least one of those types in every source folder.
That’s not how shells work.

--- bash ---
bash-3.2$ echo *.m *.mm
a.m b.m c.m *.mm

--- sh ---
$ echo *.m *.mm
a.m b.m c.m *.mm

--- zsh ---
echo *.m *.mm
zsh: no matches found: *.mm


zsh doesn’t even try if there is an error
Re: Xcode 11 broke genstrings given *.mm

Jens Alfke
 

*.{m,mm} might work better.

—Jens

On Oct 1, 2019, at 9:44 PM, Marco S Hyman <marc@snafu.org> wrote:



On Oct 1, 2019, at 9:08 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

I expect my existing working scripts using "genstrings *.m *.mm" to work, since it would find at least one of those types in every source folder.
That’s not how shells work.

--- bash ---
bash-3.2$ echo *.m *.mm
a.m b.m c.m *.mm

--- sh ---
$ echo *.m *.mm
a.m b.m c.m *.mm

--- zsh ---
echo *.m *.mm
zsh: no matches found: *.mm


zsh doesn’t even try if there is an error
Re: Xcode 11 broke my build when targeting an iPad

Alex Zavatone
 

FYI,

https://old.reddit.com/r/swift/comments/dc4zx8/xcode_11_optimization_causing_random_crashes/

On Sep 30, 2019, at 10:18 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

On Sep 30, 2019, at 13:49:48, Fritz Anderson <anderson.fritz@gmail.com> wrote:

In the spirit of is-it-plugged-in, are you running Xcode 11.0, or 11.1 (now seeded as Golden Master — that was quick)?
11.0. Is this just yet another bug they let loose on the world without proper testing, and 11.1 is planned to fix it?

--
Steve Mills
Drummer, Mac geek
Re: Xcode 11 broke genstrings given *.mm

Marco S Hyman
 

On Oct 1, 2019, at 9:08 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

I expect my existing working scripts using "genstrings *.m *.mm" to work, since it would find at least one of those types in every source folder.
That’s not how shells work.

--- bash ---
bash-3.2$ echo *.m *.mm
a.m b.m c.m *.mm

--- sh ---
$ echo *.m *.mm
a.m b.m c.m *.mm

--- zsh ---
echo *.m *.mm
zsh: no matches found: *.mm


zsh doesn’t even try if there is an error
Re: Xcode 11 broke genstrings given *.mm

Steve Mills
 

On Oct 1, 2019, at 20:50:44, Chris Hanson <cmhanson@eschatologist.net> wrote:

My suspicion is that you’re expecting “genstrings *.mm” to work in a directory that doesn’t contain any .mm files. The old genstrings would just silently ignore nonexistent files (e.g. a filename of literally “*.mm” as some shells will pass when expansion fails). Now it produces an error.
I expect my existing working scripts using "genstrings *.m *.mm" to work, since it would find at least one of those types in every source folder.

Also, I would strongly recommend adopting Xcode’s “Export for Localization…” and “Import Localizations…” feature instead of calling genstrings on your sources yourself. Doing a localization export have Xcode extract the strings from your sources, xib and storyboard files, etc. and also collect together all other localized resources, and produce a localization catalog that can be used as the basis for localization. Then your localizers can give you translated catalogs to import to produce the appropriate strings, stringsdict, and so on files for your languages. You can even set up your CI to do this since export and import are both supported in xcodebuild, not just the IDE.
My CI. That's rich. This is just me here. I'll check out the export thing. Even thought I doubt anyone will ever offer to localize any of my apps. I've just always done the genstrings thing so I'm prepared.

--
Steve Mills
Drummer, Mac geek
Re: Xcode 11 broke genstrings given *.mm

Chris Hanson
 

On Sep 30, 2019, at 8:17 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

The script is in the same place it's been for over 2 years. I know how to use Run Script build phases. And it still works for *.m. It's just broken for .mm files.
There were major changes in genstrings for Xcode 11; extractLocStrings was renamed to genstrings and brought to feature parity with the few things that genstrings did that extractLocStrings didn’t. It also had support for things like SwiftUI added.

My suspicion is that you’re expecting “genstrings *.mm” to work in a directory that doesn’t contain any .mm files. The old genstrings would just silently ignore nonexistent files (e.g. a filename of literally “*.mm” as some shells will pass when expansion fails). Now it produces an error.

Also, I would strongly recommend adopting Xcode’s “Export for Localization…” and “Import Localizations…” feature instead of calling genstrings on your sources yourself. Doing a localization export have Xcode extract the strings from your sources, xib and storyboard files, etc. and also collect together all other localized resources, and produce a localization catalog that can be used as the basis for localization. Then your localizers can give you translated catalogs to import to produce the appropriate strings, stringsdict, and so on files for your languages. You can even set up your CI to do this since export and import are both supported in xcodebuild, not just the IDE.

-- Chris
XCTests crashing user session back to login screen

Alex Zavatone
 

Has anyone seen cases where running XCTests will crash the logged in user session out to the user login screen?

Every time it happens, there are no logs that I can find explaining the cause. My suspicion is memory leaks in the iOS app I am testing and zombie pointers writing to memory outside of the simulator.

Thanks in advance.
Re: Xcode 11 broke my build when targeting an iPad

Steve Mills
 

On Oct 1, 2019, at 08:57, Fritz Anderson <anderson.fritz@gmail.com> wrote:

(Usual comment that the prevalence of possibly-dozens of reports out of a million makes it reasonable for DT to budget its time for other things. I don't say it doesn't hurt your work, just pointing out how it sucks to live in a finite universe. I'm sure you've nudged the prevalence-and-severity needle by breaking out the Feedback Assistant and reporting the issue. It's a huge improvement over the Radar site. (I wish it were available without a Spotlight search.))
Yes, bug reported. And yes, they should’ve kept the same name and domain name. After decades of automatically typing “bugr” into the Safari field and having autocomplete know what I meant, it was impossible to remember the dumb new name. I ended up adding a bookmark for it named “bugreport” so at least it still works and I don’t have to learn a new name for it.

Steve via iPhone
Re: Xcode 11 broke my build when targeting an iPad

Fritz Anderson
 

Not being an Apple employee (or being bound by a saber-toothed NDA If I were), I can't say what Developer Tools intends for the 11.1 release.

(Usual comment that the prevalence of possibly-dozens of reports out of a million makes it reasonable for DT to budget its time for other things. I don't say it doesn't hurt your work, just pointing out how it sucks to live in a finite universe. I'm sure you've nudged the prevalence-and-severity needle by breaking out the Feedback Assistant and reporting the issue. It's a huge improvement over the Radar site. (I wish it were available without a Spotlight search.))

— F

On Sep 30, 2019, at 10:18 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

On Sep 30, 2019, at 13:49:48, Fritz Anderson <anderson.fritz@gmail.com> wrote:

In the spirit of is-it-plugged-in, are you running Xcode 11.0, or 11.1 (now seeded as Golden Master — that was quick)?
11.0. Is this just yet another bug they let loose on the world without proper testing, and 11.1 is planned to fix it?

--
Steve Mills
Drummer, Mac geek
541 - 560 of 1447