Jojo’s Bizarre Adventure USA PS1 does not boot from Tonyhax

tonyhax version: latest stable version
Installation method:  using freemcboot on PS2 with ulaunchelf
Entry point game: Brunswick Circuit Pro Bowling
Console model: SCPH-39001 PS2
Integrity check: passed
BIOS version: v 5.0 02/07/02 A
Target game: Jojo’s Bizarre Adventure SLUS-01060
Bug explanation: game will not boot when I try to run it from Tonyhax I get
“missing TCB
Missing Event
Missing Stack
Missing BOOT”
“Open error 2”
then it asks me to swap CDs.
Tonyhax has worked for me for both Persona 2 and Castlevania SotN so far so i’d like to figure out the issue

It seems like the console is unable to to read the SYSTEM.CNF file in the CD. Is it an original copy or a burned disc? Is the file present? If so, can you please attach it here?

I tried two different bin/cue files I found, the latest one I found was from
https://cdromance.org/psx-iso/jojos-bizarre-adventure-usa/
https://wowroms.com/en/isos/playstation/jojos-bizarre-adventure/31866.html
I would post them directly but github is telling me .7z and .bin/.cue are unacceptable file formats to post in comments
Neither worked and they both produced the exact same results I referenced above.

What CD-R media? Have you tried different burn speeds and CD burners?

The CD-Rs that I'm using are Verbatim 80 Min standard ones from Amazon, I only have access to one burner but its been working great for everything except this game. I have only tried doing it with AWS and MAX speeds but I didn't want to waste any more discs because I wasn't sure that was the issue. I've tried it with about 6-7 other games so far and was told that Persona 2 was a good barometer for how well the CDs are burning. I got the FMVs for Persona 2 running perfectly and everything and played about an hour in with no issues so I thought I was good to go on my method/burner/CD-Rs

Also quick update as I've been burning CDs for a bit and testing them with other games: Street Fighter Alpha 3 will also not boot up and has the exact same error? Maybe it's some sort of Capcom fighting game issue? But in the same breath I should mention that Marvel vs Capcom 1 is working perfectly for me on a burned disc so idk.

I tried two different bin/cue files I found, the latest one I found was from
https://cdromance.org/psx-iso/jojos-bizarre-adventure-usa/
https://wowroms.com/en/isos/playstation/jojos-bizarre-adventure/31866.html
I would post them directly but github is telling me .7z and .bin/.cue are unacceptable file formats to post in comments
Neither worked and they both produced the exact same results I referenced above.
I'm burning them to discs with ImgBurn and now I have confirmation that Castlevania SotN, Persona 2, Digimon World 3, Metal Gear Solid all work doing this method. So it must be something with this particular game or the files I'm using

I meant the SYSTEM.CNF file alone from the CD-R.

Plugged in the CD and found it in the root, it won't let me upload a .CNF file I guess but this is exactly what it says
" BOOT = cdrom:\SLUS_010.60;1
TCB = 4
EVENT = 16
STACK = 801fff00
"

Can you please ZIP the .CNF file and upload that? It could be that some encoding oddity only visible on an hex editor is causing the config file load process to fail.

Alright I've checked and the file seems to be alright. So not sure what @alex-free would think about it, but it seems like a dying drive to me.

Alright I've checked and the file seems to be alright. So not sure what @alex-free would think about it, but it seems like a dying drive to me.

The CD-Rs being used are the absolute worst quality, I have a chart on my findings here: https://alex-free.github.io/psx-cdr/#cd-r-media
I recommend CMC Pro powered by Taiyo Yuden technology, which are the best still made brand new to this day.
While playing around with different constant write burn speeds may make this work (or the vertical trick: https://alex-free.github.io/psx-cdr/), or even perhaps refurbishing the drive (https://alex-free.github.io/unofficial-ps1-cd-drive-service-manual/), I don't trust those CD-Rs at all. While one game may work, that doesn't mean all will with poor quality CD-Rs.
I'm pretty sure I've played at least one of the mentioned titles before. Unfortunately I'm not in a position to test real hardware for a bit.
Seriously, try flipping the console vertical like this: https://github.com/alex-free/tonyhax/issues/28#issuecomment-1578810496
@socram8888 for testing the system cnf parsing emulation is definitely fine.

I am wondering why FileRead isn't returning -1 as documented in the no$psx docs, if it's a true read error. I do check for that in the secondary.c code. Is it just returning all zeros or what?

@SpyrooftheNight could you please try with this version that has some extra sanity checks? tonyhax-v1.4.6b.zip

KK I'll try that version of tonyhax right now to see if it works, will take a second to flash my mem card and everything. Just to be sure, you don't need me to zip the CNF file anymore right?

No no, thanks, no need for the ZIP file. To be clear, this version of tonyhax should not fix any issue - it just shows more information on screen about the failure mode (ie why the file could not be processed).

OK I've installed the version you linked, and run into the same error. Do you want me to take a picture of the screen or is there a file I need to go look for now?

OK I've installed the version you linked, and run into the same error. Do you want me to take a picture of the screen or is there a file I need to go look for now?

The same error code happens with his version? I think the idea is it should be more verbose/accurate and the text should be slightly different.
Did you try the vertical trick?
There is a slim chance that Tonyhax International may read the game since it handles disc reading a bit differently. In the past I've noticed it more reliably boots poor quality CD-Rs better then i.e UniROM. May be worth a try (https://github.com/alex-free/tonyhax?tab=readme-ov-file#downloads).
If possible order the CMC Pro CD-Rs (they are on Amazon) or try different burn speeds with your current Verbatim CD-R.

Seems like its the same info. The vertical trip is just to stand it up vertically right?

Seems like its the same info. The vertical trip is just to stand it up vertically right?

Indeed looks the same.
Vertical trick is indeed just standing the console on its side. Also try diagonal angles and upside down.

I know it might not be helpful but in my googling I did come across someone on reddit talking about a similar error with Resident Evil 2 and referencing this issue thread: https://github.com/socram8888/tonyhax/issues/24
I can't really decipher what's being said in the discussion but it seems like the guy found a fix eventually ?
CMC CDs are ordered and on the way but it'll take a few days to get them so probably going to do some trial and error with these ones and different writing speeds and the vertical trick I guess. Seems weird that the two I'm having issues with are both Capcom fighters but I guess thats just my luck.

I know it might not be helpful but in my googling I did come across someone on reddit talking about a similar error with Resident Evil 2 and referencing this issue thread: https://github.com/socram8888/tonyhax/issues/24
I can't really decipher what's being said in the discussion but it seems like the guy found a fix eventually ?
CMC CDs are ordered and on the way but it'll take a few days to get them so probably going to do some trial and error with these ones and different writing speeds and the vertical trick I guess. Seems weird that the two I'm having issues with are both Capcom fighters but I guess thats just my luck.

Huh, does Resident Evil 2 work on your console or do you get the same issue?

No I can't so that's now Resident Evil 2, Street Fighter Alpha 3 and Jojo's Bizarre Adventure that all givr the same exact errors where all my other games are working flawlessly without any issues when I play them

No I can't so that's now Resident Evil 2, Street Fighter Alpha 3 and Jojo's Bizarre Adventure that all givr the same exact errors where all my other games are working flawlessly without any issues when I play them

Woah, really? Can you try patching the bin file with https://github.com/alex-free/psx80mp?tab=readme-ov-file#downloads and then burning another disc of the patched image?

For Resident Evil 2 right?

For Resident Evil 2 right?

Any of the above. If you patch any of the problematic games it might work.

Ok So I'm patching ONLY track 1 for RE2 right? Leave track 2 bin alone? And I just drag the bin onto the .exe and its done?

OK So Resident Evil 2 now works and boots flawlessly with that patch. Let me check Jojos and SFA3

OK So Resident Evil 2 now works and boots flawlessly with that patch. Let me check Jojos and SFA3

@socram8888 i can't belive it https://github.com/socram8888/tonyhax/issues/24 wasn't PS1 specific after all!
I will have to update Tonyhax international to apply the software workaround for all consoles (and not just PS2s).

Hm OK so Jojo's also works great after the patch, played a few matches and everything. But Street Fighter Alpha 3 now gets off the boot screen and doesn't have any of the "Missing TCB, Missing Event, etc." but when it boots up its just a black screen and it stays black? I know SFA3 was released pretty late in the PS1's life so it might have extra protection? And it's not terribly priced so I could probably just get a legit copy but if its fixable or something I'd love to know what I could do next? Would patching the 2nd track for SFA3 help at all?

Hm OK so Jojo's also works great after the patch, played a few matches and everything. But Street Fighter Alpha 3 now gets off the tonyhax screen and doesn't have any of the "Missing TCB, Missing Event, etc." but when it boots up its just a black screen and it stays black? I know SFA3 was released pretty late in the PS1's life so it might have extra protection? And it's not terribly priced so I could probably just get a legit copy but if its fixable or something I'd love to know what I could do next? Would patching the 2nd track for SFA3 help at all?

My thinking is the black screen thing in SFA3 is unrelated to the original issue.  Does the vertical trick get around it?
The way I see it, the black screen issue in SFA3 could be caused by:

SFA3 could have an FMV (not sure, will find out soon) at boot that doesn't read correctly from the Verbatim CD-R and causes the drive to give up before loading past the black screen after Tonyhax loads the game. Vertical trick could fix that if it is the problem.

There could be some issue caused by the patcher, but I think this is extremely unlikely. This game could possibly use SubchannelQ instead of TOC data to seek to the audio track.   I know the first 2 Tomb Raider games work that way. http://redump.org/disc/508/ does mention 2 tracks. I'm not sure if the patcher would be problematic with such games.

There could  be EDC or some other protection (redump is inaccurate at that, so I don't trust the redump page that says nothing is present).

I'm gonna take a look in an emulator in a bit.

You could also try this  patcher for SFA3:  https://github.com/socram8888/tonyhax/files/11782073/ps26mp-1.0.1-windows_x86.zip

should I patch the same file I already patched or patch a fresh file ? Thank you so much for the time and patience by the way, I never expected to get this problem resolved today and I honestly was about to give up on playing Jojos in 240p, so seriously you guys are awesome.

should I patch the same file I already patched or patch a fresh file ? Thank you so much for the time and patience by the way, I never expected to get this problem resolved today and I honestly was about to give up on playing Jojos in 240p, so seriously you guys are awesome.

That's why we do this ;)
Try to use the ps26mp patcher on a fresh file. It's essentially an older version of the psx80mp patcher that works a bit differently (and maybe could get SFA3 to work).
If that doesn't work, I have another trick up my sleeve.

@socram8888 snippet.txt is what is happening between exe launch (black screen) to this first screen:
 . Used duckstation log.
snippet.txt
The patched disc image worked fine via emulation (directly booting the patched disc image).

Disregard the vertical trick, I thought you had a PS1 this makes way more sense.

If the ps26mp patcher also doesn't work, this is the trick up my sleeve.

Burn a fresh SFA3 with no patch.
Download https://alex-free.github.io/tonyhax-international/#downloads  . You want entrypoints/BASLUS-00571 and loader\HAX on the PS1 memory card. More info on this: https://alex-free.github.io/tonyhax-international/save-game-exploit.html#usage .
Try booting the fresh unpatched SFA3 with Tonyhax International.

Tonyhax International has a software-based fix for the SYSTEM.CNF issue, which could possibly work if the patcher isn't working for some reason for this specific game on real hardware.

I actually started patching/burning right after my comment and wanted to see how it turned out. So I patched the track file that I already patched with the other .exe and it seems to have worked. I also patched the track 2 file just in case that would help. But I just played a match as R. Mika and it seemed that everything was working perfectly and the FMV at the beginning played smooth and perfect.
Still going to get those CMC disks to cover my bases but I'm glad I got the two games I was having issues with to play. Seriously its insane to me you guys were able to troubleshoot this so fast, I really appreciate the work you guys have done. As of right now the problem is a non-problem and if I have any issues with other games I guess my go-to should be to try patching them if I have this issue again. Have a good one and thank you again! I should "close" the issue thread right?

I actually started patching/burning right after my comment and wanted to see how it turned out. So I patched the track file that I already patched with the other .exe and it seems to have worked. I also patched the track 2 file just in case that would help. So right now with both patches or just the second patch I guess, SFA3 works with tonyhax! I just played a match as R. Mika and it seemed that everything was working perfectly and the FMV at the beginning played smooth and perfect.
Still going to get those CMC disks to cover my bases but I'm glad I got the two games I was having issues with to play. Seriously its insane to me you guys were able to troubleshoot this so fast, I really appreciate the work you guys have done. As of right now the problem is a non-problem and if I have any issues with other games I guess my go-to should be to try patching them if I have this issue again. Have a good one and thank you again! I should "close" the issue thread right?

Haha nice! Would you mind checking that the ps26mp patcher alone works? I'd really like to try myself but can't test real hardware ATM and it would be good to know, because I have an idea on how to fix the psx80mp patcher if the ps26mp patcher by itself works

Yeah of course! Give me a couple minutes to download and patch/burn.

Ok patched Track 1 with ONLY ps26mp and it booted past tonyhax but we're back at the black screen and it's not loading that starter image.

Ok patched Track 1 with ONLY ps26mp and it booted past tonyhax but we're back at the black screen and it's not loading that starter image.

What if you only patch track 2 with ps26mp? I have a weird theory for that. Thank you for your CD-R sacrifices.

Yeah, so fresh rom, this time ONLY track 2 with ps26mp, gimme a few. And, well I have 100 more coming in a few days that are better quality so mind as well get rid of the shitty ones in a productive way haha.

Yeah, so fresh rom, this time ONLY track 2 with ps26mp, gimme a few. And, well I have 100 more coming in a few days that are better quality so mind as well get rid of the shitty ones in a productive way haha.

Literally making my night testing out this theory!  I'm in the middle of a move so I haven't been able to work on things like I'd like to.
If only patching track 2 with ps26mp works, could I also trouble you to try only track 2 patching with psx80mp?
See @socram8888 this is the only PSX game I have ever seen with 2 data tracks! Seriously, I have never seen a sync pattern in track 2. I thought any multi-track games would have 1 data track and then some audio tracks. Redump listed it as a data track too, looks like nothing in it but the sync header and dummy data.

OK so track 2 patched by ps26mp works and boots perfectly so far. Now I'll do a fresh rom and try to patch track 2 with psx80mp and let you know the results

OK so track 2 patched by ps26mp works and boots perfectly so far. Now I'll do a fresh rom and try to patch track 2 with psx80mp and let you know the results

Incredible! YOU figured this out with track 2! I never would have thought that could have worked, because PS1 games don't usually work that way.

Track 2 ONLY patched with psx80mp does NOT work. That's pretty cool, it was a lucky guess. Anything else you need me to test??

Track 2 ONLY patched with psx80mp does NOT work. That's pretty cool, it was a lucky guess. Anything else you need me to test??

Yes, I think I can fix psx80mp to work with track 2 but I'll need to write some code. Can I ping you in a bit?

Yeah of course, i'll be down to test it when you're ready.

Yeah of course, i'll be down to test it when you're ready.

Excellent. Lets try this first. Only patch track 2 on a fresh SFA3 image using the attached patcher.
psx80mp-v2.0.1-BETA1-windows-x86_64.zip

That way worked and booted up exactly as expected.

That way worked and booted up exactly as expected.

BETA1 works as expected by only patching track 2?!

Yep it went right into the SFA 3 image and then the FMV intro and just played a few matches!

To Socram8888: You were right that the software fix could potentially fail after boot if the game exe itself tried to load data towards the edge of the written part of the CD-R.  SFA3 is that prophetical edge-case. While  we can seek in steps to guarantee loading of the SYSTEM.CNF and PSX-EXE, we can not do anything software-wise after booting the executable. So while the sotware-fix in Tonyhax International does get more games working, it is not 100% like the patcher appears to be with every problematic title we've found so far.
I guess this issue can be closed now then! I will push an update to PSX80MP to make it work with SFA3 and some other enhancements.

Thank you so much for testing @SpyrooftheNight !

Thanks for all the work you guys do, was glad to be of help!

Seems like its the same info. The vertical trip is just to stand it up vertically right?

I don't fully comprehend what is going on. The extra checks that are performed there are:

That means something is actually being read?
Anyway, glad you got it working now!

Seems like its the same info. The vertical trip is just to stand it up vertically right?

I don't fully comprehend what is going on. The extra checks that are performed there are:

That means something is actually being read?
Anyway, glad you got it working now!

Same hardware issue as https://github.com/socram8888/tonyhax/issues/24 . PS2 can't recover after accidentally over-seeking and 'reading' Unburned area past lead-out in tightly wound 80 minute media. So the file exists in the directory table but on seek it fails. No issue with secondary.c code or additional handling needed (or possible from what I can tell).

Yeah but the weird thing is, if seek is failing, what on earth is it reading? If @SpyrooftheNight is up to, I'd like to send him another version that displays on screen what the buffer contains after FileRead returns.

You can send me another version to test out but I won't be able to get around to it for a couple hours. I still have to reinstall the latest build of tonyhax from the one you told me to switch to anyway so I can just do that before I flash it back.

tonyhax-v1.4.6b.zip

This version should show on the screen the contents of the SYSTEM.CNF being read. If you could take a photo that'd be really useful.

So you want me to try and use an unpatched fresh SFA3 on it to see what it returns? I'll be able to do it in a hour or so

Yes, that is correct!

Got held up with something but working on it now, just out of curiousity when I replace the Tonyhax on my memory card do I need to replace both the save for my exploitable game AND Tonyhax save or just the tonyhax one?

Generally, no. The exploit files have remained the same since 1.2 I think.

Here's what I got for ya!

Alright, many thanks! I can't find anything on the entire game .bin file that matches that pattern, so I have genuinely no idea what is it reading.

¯_(ツ)_/¯ I'm just glad we figured out a fix for whatever was going on. Let me know if you need any more testing done! Thanks again

Alright, many thanks! I can't find anything on the entire game .bin file that matches that pattern, so I have genuinely no idea what is it reading.

I wonder if we are looking at post-lead-out?

I found out another one that requires the patch is Final Fantasy IX. First disc wouldn't boot without patching so I applied the patch to all .bins/discs just in case and it works. If I run into any other games that require the patch I can update this comment. So far its:
-Jojo's Bizarre Adventure
-Street Fighter Alpha 3 (need to patch track 2 not 1)
-Resident Evil 2
-Final Fantasy IX
Just wanna make it as clear as possible for anyone that has this problem in the future thats a laymen like me.

I found out another one that requires the patch is Final Fantasy IX. First disc wouldn't boot without patching so I applied the patch to all .bins/discs just in case and it works. If I run into any other games that require the patch I can update this comment. So far its:
-Jojo's Bizarre Adventure -Street Fighter Alpha 3 (need to patch track 2 not 1) -Resident Evil 2 -Final Fantasy IX
Just wanna make it as clear as possible for anyone that has this problem in the future thats a laymen like me.

Thank you for your findings. The PSX80MP v2.0.1 Update is out now, with better documentation and a list of every known game disc that needs to be patched. This list includes what track number to patch as well (1 or 2): https://github.com/alex-free/psx80mp?tab=readme-ov-file#confirmed-80-minute-sensitive-games
To further help others, please open an issue here https://github.com/alex-free/psx80mp/issues/new if you come across any more titles so they may be added to the list above.


[WIP]: Create RPC service for throttler and add it to vttablet.

@alainjobart
Alain, please have a look at the different commits.
For now, I decided to have a singleton instance for the throttler.Manager. New throttlers automatically register with this manager and unregister upon Close(). Having the manager as singleton simplifies things e.g. registering it for gRPC in vttablet. Do you agree?

This change is

Looks good!
Previously, michael-berlin (Michael Berlin) wrote…
> #### \[WIP\]: Create RPC service for throttler and add it to vttablet\.
>
> @alainjobart
>
>
>
> Alain, please have a look at the different commits.
>
>
>
> For now, I decided to have a singleton instance for the throttler.Manager. New throttlers automatically register with this manager and unregister upon Close(). Having the manager as singleton simplifies things e.g. registering it for gRPC in vttablet. Do you agree?
>
>
>

Reviewed 23 of 23 files at r1.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

go/vt/throttler/manager.go, line 17 [r1] (raw file):

var GlobalManager = newManager()

// Manager controls multiple throttlers and also aggregates their statistics.

Good idea to expose stats at the manager level. Although obviously this is not implemented yet hehe.

go/vt/throttler/throttlerclienttest/throttlerclient_testsuite.go, line 36 [r1] (raw file):

	tf.setMaxRate(t, c)

	// TODO(mberlin): Add a test for panic handling.

And add an actual panic handler somewhere... :)

Comments from Reviewable

Previously, alainjobart (Alain Jobart) wrote…
> Looks good!

Reviewed 10 of 23 files at r1, 13 of 13 files at r2.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

proto/throttlerdata.proto, line 26 [r2] (raw file):

message SetMaxRateResponse {
  // names is the list of throttler names which were updated.
	repeated string names = 1;

looks like wrong indentation

Comments from Reviewable

Alain, I've added the panic  handler and respective tests for it.
Previously, enisoc (Anthony Yeh) wrote…
> :lgtm:

Review status: 17 of 23 files reviewed at latest revision, 3 unresolved discussions.

proto/throttlerdata.proto, line 26 [r2] (raw file):
Previously, enisoc (Anthony Yeh) wrote…
> looks like wrong indentation

Done.

Comments from Reviewable


the axisPointer ,what will keep him alive?

Version
4.3.0
Steps to reproduce

move the mouse ,Beyond both sides of the X-axis ,the axisPointer will disappear

What is expected?
axisPointer can always alive
What is actually happening?
move the mouse ,Beyond both sides of the X-axis ,the axisPointer will disappear

滑动鼠标或者移动手势，当超过X轴边界，axisPointer会消失。
期望当滑动axisPointer超过X轴边界时，固定axisPointer 在X轴边界。
代码部分上传地址： https://jsfiddle.net/meufzqwa/

Hi, I found the solution may be useful for this.
Apply the following on the xAxis.
axisPointer: {       handle: {         show: true,         color: '#d1554e',         size: 0,       },     },
Reproduce code: https://jsfiddle.net/qhetcp60/
Hope it's helpful.


Save and call pre-existing native handler on Android

This is in part a workaround to #62 (since I can't manually call that pre-existing handler) but I think it's generally better behavior for react-native-exception-handler to not completely overwrite pre-existing native handlers.
Fixes #65
This should also be done for the iOS native handler but I am having other issues with the iOS native handler code (see issue #63) so I couldn't properly test it.  I've filed #66 for that.

Will release this in v2.8.7

V2.8.9 is out ! @mark-friedman

Thanks, @master-atul!


HyperLinkPropertyEditor Nullreference

Hi Tolis,
I converted the first project to .net6. With the HyperLinkPropertyEditor I get the error
iXISXRM.Win Error: 0 : 21.10.22 17:36:01.687	================================================================================
The error occurred:

	Type:       InvalidOperationException
	Message:    Exception occurs while assigning the 'XpandDetailView, ID:XpandPermissionPolicyUser_DetailView' view to XpandWinWindow:
Object reference not set to an instance of an object.
	Data:       0 entries
	Stack trace:

   at DevExpress.ExpressApp.Frame.SetView(View view, Boolean updateControllers, Frame sourceFrame, Boolean disposeOldView)
   at DevExpress.ExpressApp.Win.WinShowViewStrategyBase.CreateWindow(ShowViewParameters parameters, ShowViewSource showViewSource, Boolean isMain)
   at DevExpress.ExpressApp.Win.MdiShowViewStrategy.CreateInspectorWindow(ShowViewParameters parameters, ShowViewSource showViewSource)
   at DevExpress.ExpressApp.Win.MdiShowViewStrategy.ShowViewInInspector(ShowViewParameters parameters, ShowViewSource showViewSource)
   at DevExpress.ExpressApp.Win.WinShowViewStrategyBase.ShowViewInNewWindow(ShowViewParameters parameters, ShowViewSource showViewSource)
   at DevExpress.ExpressApp.Win.MdiShowViewStrategy.ShowViewInCurrentWindow(ShowViewParameters parameters, ShowViewSource showViewSource)
   at DevExpress.ExpressApp.Actions.ActionBase.ExecuteCore(Delegate handler, ActionBaseEventArgs eventArgs)
	----------------
	InnerException:

			Type:       NullReferenceException
			Message:    Object reference not set to an instance of an object.
			Data:       0 entries
			Stack trace:

   at Xpand.ExpressApp.Win.PropertyEditors.HyperLinkPropertyEditor.CreateControlCore()
   at DevExpress.ExpressApp.Editors.ViewItem.CreateControl()
   at DevExpress.ExpressApp.Win.Layout.WinLayoutManager.controlItem_QueryControl(Object sender, QueryControlEventArgs e)
   at DevExpress.ExpressApp.Win.Layout.XafLayoutControlItem.RaiseQueryControl()
   at DevExpress.ExpressApp.Win.Layout.XafLayoutControlItem.EnsureControl()
   at DevExpress.XtraLayout.BaseLayoutItem.SetVisible(Boolean lVisible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChild(BaseLayoutItem item, Boolean visible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChildren(Boolean visible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChild(BaseLayoutItem item, Boolean visible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChildren(Boolean visible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChild(BaseLayoutItem item, Boolean visible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChildren(Boolean visible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChild(BaseLayoutItem item, Boolean visible)
   at DevExpress.XtraLayout.LayoutGroup.UpdateChildren(Boolean visible)
   at DevExpress.XtraLayout.LayoutControlImplementor.UpdateRoot()
   at DevExpress.XtraLayout.LayoutControlImplementor.InvalidateRootOffsetControlsAndScrolls()
   at DevExpress.XtraLayout.LayoutControlImplementor.Invalidate()
   at DevExpress.XtraLayout.LayoutDesignerMethodsProvider.DevExpress.XtraLayout.ILayoutDesignerMethods.EndChangeUpdate()
   at DevExpress.XtraLayout.LayoutControlImplementor.ProcessLookAndFeelStyleChanged()
   at DevExpress.XtraLayout.LayoutControlImplementor.OnLookAndFeelStyleChanged(Object sender, EventArgs e)
   at DevExpress.XtraLayout.LayoutControlImplementor.EndInitCore()
   at DevExpress.ExpressApp.Win.Layout.WinLayoutManager.LayoutControls(IModelNode layoutNode, ViewItemsCollection viewItems)
   at DevExpress.ExpressApp.View.CreateControls()
   at DevExpress.ExpressApp.Win.Templates.ViewSiteManager.EnsureViewControl()
   at DevExpress.ExpressApp.Win.Templates.ViewSiteManager.FillViewSite()
   at DevExpress.ExpressApp.Win.Templates.Ribbon.DetailRibbonFormV2.DevExpress.ExpressApp.Templates.IFrameTemplate.SetView(View view)
   at DevExpress.ExpressApp.Frame.SetTemplateView(View view)
   at DevExpress.ExpressApp.Frame.SetView(View view, Boolean updateControllers, Frame sourceFrame, Boolean disposeOldView)
			InnerException is null

I can not repro it in a new blank project. Do you have an idea?

not anyrthing that will makse sense given the exception site

hi, once you give an instruction how to debug with the expand code. But I can´t find it anymore. Can you help me?

I am not sure what u looking for the symbols are distributed with nuget so once in your bin this applies
https://github.com/eXpandFramework/Reactive.XAF/wiki/How-to-boost-your-DevExpress-Debugging-Experience

however u could also copy the source code of the editor add it in your source code, change the namespqace and use it instead. It will break in your code.


fix(jsii): document location of initializers in source

Those were previously not recorded, although the assembly schema supports
recording this information.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: d7390a8f5847cb969d64e4c609b6b2b0c70bdf92
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


strikethrough (delete) not supported

Hi @inokawa !
Thanks for the contribution, I was wondering how to add support to "strikethrough" , I'm quite new to how this works and I would like to add support to it, I see that "strikethrough" in mdast is called Delete which apparently should be supported by remark-stringify which is a wrapper for mdast-to-markdown.
The last one doesn't support "delete", is there anyway that you can think of to support it?

Hi @jepser . Thank you for considering my library!
This library supports strike-through already.
If you use remark-parse or remark-stringify and this with remark-gfm, you can convert strike-through.
If you have any questions, please ask me again.

Hey thanks for your super quick response, sorry if my question is basic but... how come would you do that?
I have tried from let's say ~~this should be strike through~~
const toRemark = unified()
  .use(slateToRemark)
  .use(stringify);

const tree = toRemark.runSync({
      type: 'root',
      children: astValue,
    });
    const stringifiedValue = toRemark.stringify(tree, {
      extensions: [gfm.toMarkdown()],
    });

also by removing gfm.toMarkdown() to the toRemark processor:
const toRemark = unified()
  .use(slateToRemark)
  .use(stringify, {
    extensions: [gfm.toMarkdown()],
  });

where gfm is: https://github.com/syntax-tree/mdast-util-gfm
Any ideas, it will so much be appreciated

Thanks for taking the time to answer!
No, the code is taken from an example, you're right with the format, the bold/italic/delete is set in the leaf. I will try with the code of the storybook (why I didn't think about that before 😅).

Interesting, it worked with remark-gfm, I really appreciate your help!


Fix: 'visualbell' doesn't work

repro steps
test-environments:

macOS 10.12.5, Terminal.app
Ubuntu 16.04, gnome-terminal

vim -Nu NONE -c 'set vb'

and input h, but expected visual-bell (flashing screen) doesn't happen.
details
Vim sends terminal-control-sequences at visualbell event when t_vb is ^[[?5h$<100/>^[[?5l:
expected: CSI ?5h (reverse video) → 100ms delay → CSI ?5l (normal video)
actual:   100ms delay → CSI ?5h (reverse video) → CSI ?5l (normal video)
cause
At visualbell event, tputs() in out_str(T_VB) is called,
and out_char_nf() writes characters of T_VB except $<100/> (terminfo string) to out_buf.
$<100/> is interpreted and executed before out_buf is flushed.
100ms delay by "$<100/>" in tputs()
out_flush() flushes out_buf (=="\e[?5h\e[?5l")

proposal of fix
T_VB has to be flushed, at least, before $<...>.
desirable sequence:
tputs("\e[?5h")
out_flush()
tputs("$<100/>\e[?5l")

This patch adds out_str_cf() to check $< in T_VB and to insert flushing.
Ozaki Kiichi

Codecov Report

Merging #1789 into master will decrease coverage by 0.02%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1789      +/-   ##
==========================================
- Coverage   75.08%   75.06%   -0.03%
==========================================
  Files          76       76
  Lines      125067   125085      +18
==========================================
- Hits        93907    93895      -12
- Misses      31160    31190      +30

Impacted Files
Coverage Δ

src/term.c
52.41% <0%> (-0.57%)
:arrow_down:

src/misc1.c
82.68% <0%> (ø)
:arrow_up:

src/if_xcmdsrv.c
85.18% <0%> (-0.93%)
:arrow_down:

src/gui_gtk_x11.c
47.39% <0%> (-0.11%)
:arrow_down:

src/ex_cmds2.c
79.6% <0%> (-0.11%)
:arrow_down:

src/channel.c
83.8% <0%> (-0.1%)
:arrow_down:

src/evalfunc.c
81.6% <0%> (-0.03%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4670490...9ae7892. Read the comment docs.

Sorry, I wrote an incorrect content of "cause". I have revised it.

Ozaki Kiichi wrote:

repro steps
test-environments:

macOS 10.12.5, Terminal.app
Ubuntu 16.04, gnome-terminal

vim -Nu NONE -c 'set vb'

and input h, but expected visual-bell (flashing screen) doesn't happen.
details
Vim sends terminal-control-sequences at visualbell event when t_vb is ^[[?5h$<100/>^[[?5l:
expected: CSI ?5h (reverse video) → 100ms delay → CSI ?5l (normal video)
actual:   100ms delay → CSI ?5h (reverse video) → CSI ?5l (normal video)
cause
At visualbell event, tputs() in out_str(T_VB) is called,
and out_char_nf() is called by every characters of T_VB except $<100/> (terminfo string).
$<100/> is interpreted and executed in tputs() in advance of calling out_char_nf().
in tputs():

[100ms delay by "$<100/>"]
out_char_nf('\e')
out_char_nf('[')
out_char_nf('?')
out_char_nf('5')
out_char_nf('h')
out_char_nf('\e')
out_char_nf('[')
out_char_nf('?')
out_char_nf('5')
out_char_nf('l')

This may depend on the implementation.  For me it appears there is no
delay at all.

proposal of fix
T_VB has to be flushed, at least, before $<...>.
desirable sequence:
tputs("\e[?5h")
out_flush()
tputs("$<100/>\e[?5l")

This patch adds out_str_cf() to check $< in T_VB and to insert flushing.

It appears this doesn't work for me. I actually liked the tiny flash,
making it flash for 200 msec would be a problem.  Especially when it
repeats.
How about this solution, using your patch but changing out_str_cf():
void

out_str_cf(char_u *s)
{
#ifdef ELAPSED_FUNC
static int		did_init = FALSE;
static ELAPSED_TYPE start_tv;
#endif
if (s != NULL && *s)
{
char_u *p;

#ifdef FEAT_GUI
/* Don't use tputs() when GUI is used, ncurses crashes. */
if (gui.in_use)
{
out_str_nf(s);
return;
}
#endif
if (out_pos > OUT_SIZE - 20)
out_flush();
#ifdef HAVE_TGETENT
for (p = s; s; ++s)
{
/ flush just before delay command */
if (*s == '$' && *(s + 1) == '<')
{
char_u save_c = *s;
	*s = NUL;
	tputs((char *)p, 1, TPUTSFUNCAST out_char_nf);
	*s = save_c;

ifdef ELAPSED_FUNC
	/* Only sleep once per second, otherwise a sequence of beeps
	 * would freeze Vim. */
	if (!did_init || ELAPSED_FUNC(start_tv) > 1000)
	{
	    do_sleep(100);
	    ELAPSED_INIT(start_tv);
	    did_init = TRUE;
	}
	p = vim_strchr(s, '>');
	if (p == NULL)
	    p = s;
	else
	    ++p;

else
	/* Rely on the terminal library to sleep. */
	out_flush();
	p = s;

endif
	break;
    }
}
tputs((char *)p, 1, TPUTSFUNCAST out_char_nf);

#else
while (*s)
out_char_nf(*s++);
#endif
/* For testing we write one string at a time. */
if (p_wd)
    out_flush();
}

}
This way we can make the delay configurable with a option, instead of a
weird terminal-dependend escape code.
--
hundred-and-one symptoms of being an internet addict:
85. Choice between paying Compuserve bill and paying for kids education
is a no brainer -- although a bit painful for your kids.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I updated patch.

Add do_visualbell() to adjust the interval of visualbell flashing

It appears this doesn't work for me. I actually liked the tiny flash,
making it flash for 200 msec would be a problem.  Especially when it
repeats.

I agree, but I think it would be better not to include specific process for visual-bell into out_str_cf() and better to add new function to control.
I'd like to make out_str_cf() purely handle terminal-strings.
I set 200msec intervals of visualbell. I felt 1sec intervals are less responsiveness of flashing to input (e.g. at key-repeat).

Thanks.  I think we should apply the restriction of once per second also to the normal bell.  I don't think anyone counts on lots of bells :-)

Ozaki Kiichi wrote:

I updated patch.

Add do_visualbell() to adjust the interval of visualbell flashing

It appears this doesn't work for me. I actually liked the tiny flash,
making it flash for 200 msec would be a problem.  Especially when it
repeats.

I agree, but I think it would be better not to include specific
process for visual-bell into out_str_cf() and better to add new
function to control.  I'd like to make out_str_cf() purely handle
terminal-strings.

OK, but I think we should also limit the normal bell.  I know terminals
that turn it into a visual bell and then one has to wait for the
flashing to finish.

I set 200msec intervals of visualbell. I felt 1sec intervals are less
responsiveness of flashing to input (e.g. at key-repeat).

I found 200 msec too short, since the visual flash could be 200 msec.
Half a second seems like a good compromise.
I submitted the change, please check if it works OK now.
--
You can't have everything.  Where would you put it?
-- Steven Wright
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I don't think anyone counts on lots of bells :-)

I do actually, and it took me quite some time to figure out that this was the cause of this (reason for this is below). I am currently using a recompiled version of Vim (with a part of misc1.c commented out) but I would appreciate an option to adjust the half a second delay to, say, 0.

OK, but I think we should also limit the normal bell. I know terminals that turn it into a visual bell and then one has to wait for the flashing to finish.

That is a good reasoning, but even in that case, some other terminals do audible bells. VX Connectbot (Android) even uses vibrate.
In any case, the 200 ms delay for the visual bell could also be configurable. If the first two people who write to this issue are already disagreeing on the length of time, other people will want it differently, too.
In case anyone is interested in the reason why I sometimes hold down a key to hear the bell repeating: the bell sound I use is kind of soothing and repeating it adds rhythm to that. It lets me relax in between the programming work :-). Plus, it's always good to know that no programs are currently slowing down the computer.


Missing mime type for .jfif

https://github.com/jshttp/mime-types/blob/master/README.md#adding-types


feat: add qml common component import by qrc examples and fix some no…

add a more complex qml usage example(you can import other predefined qml file in your main.qml with bazel)
fix non engine problem

when you use mouse click on picture1, you will see very likely result in picture2

Sorry - in the meanwhile I moved all examples to the folder tests

ok, i will close this and open a new pr


Change the admin theme to Gin and remove Claro

This PR does the following:

Removed support for the Claro Admin theme
Installs the Gin admin theme

Notes:

Gin is a new core theme with a rigorously tested design system: https://www.drupal.org/docs/8/core/themes/gin-theme/design.
Accessibility is a driving focus of gin.
The color palette is fairly neutral.
Support and bug fixes will be bundled with core updates.

@Gregg-Hendrix This looks good to me! One small change we'll need in the other repo in order to consider this complete.

checkout the sous-drupal-project and switch your branch to 4.x-beta.
Create a new branch with the same name as this one.
Update this line to gin - https://github.com/fourkitchens/sous-drupal-project/blob/2.x/sous/Starter.php#L32
Create a PR with this change and tag me.

Once that is complete we should be in a good spot to merge these and have a fully updated install.

:tada: This PR is included in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add unsupported operation exception to iterators remove function

From<EMAIL_ADDRESS>on February 16, 2011 08:19:28
In Node and NodeChildren
Original issue: http://code.google.com/p/rest-assured/issues/detail?id=33

From<EMAIL_ADDRESS>on February 15, 2011 23:19:43
Status: Duplicate
Mergedinto: 32


Crash in Metal from MTLReleaseAssertionFailure

From b/197827241
This appears to be different from https://github.com/flutter/flutter/issues/88884 since I don't see any references to MultiFrameCodec in the backtrace. Maybe the fix from https://github.com/flutter/flutter/issues/69102 was broken somehow?
/cc @gaaclarke @jvanverth @chinmaygarde
Thread 4  (id: 0x0000a303) CRASHED [EXC_SOFTWARE / SIGABRT @ 0x00000001d0185334 ]Show exception record
0x00000001d0185334(libsystem_kernel.dylib + 0x00029334)__pthread_kill
0x00000001edc09a98(libsystem_pthread.dylib + 0x00002a98)pthread_kill
0x00000001ab361b80(libsystem_c.dylib + 0x00077b80)abort
0x00000001b823e2dc(Metal + 0x000982dc)MTLReleaseAssertionFailure
0x00000001df7cb44c(IOGPU + 0x0000344c)-[IOGPUMetalCommandBuffer setCurrentCommandEncoder:]
0x00000001b822e25c(Metal + 0x0008825c)-[_MTLCommandEncoder initWithCommandBuffer:]
0x00000001df7cd108(IOGPU + 0x00005108)-[IOGPUMetalCommandEncoder initWithCommandBuffer:]
0x00000001ef2e7640(AGXMetalA13 + 0x002e7640)
0x00000001ef01ad0c(AGXMetalA13 + 0x0001ad0c)
0x0000000107a665cc(Flutter -GrMtlCommandBuffer.mm:46)GrMtlCommandBuffer::getBlitCommandEncoder()
0x0000000107a69550(Flutter -GrMtlGpu.mm:410)GrMtlGpu::onWritePixels(GrSurface*, int, int, int, int, GrColorType, GrColorType, GrMipLevel const*, int, bool)
0x000000010797b368(Flutter -GrGpu.cpp:449)GrGpu::writePixels(GrSurface*, int, int, int, int, GrColorType, GrColorType, GrMipLevel const*, int, bool)
0x000000010798d4cc(Flutter -GrResourceProvider.cpp:731)GrResourceProvider::writePixels(sk_sp<GrTexture>, GrColorType, SkISize, GrMipLevel const*, int) const
0x000000010798de20(Flutter -GrResourceProvider.cpp:138)GrResourceProvider::createTexture(SkISize, GrBackendFormat const&, GrColorType, GrRenderable, int, SkBudgeted, SkBackingFit, GrProtected, GrMipLevel const&)
0x000000010798607c(Flutter -GrProxyProvider.cpp:329)std::__1::__function::__func<GrProxyProvider::createNonMippedProxyFromBitmap(SkBitmap const&, SkBackingFit, SkBudgeted)::$_0, std::__1::allocator<GrProxyProvider::createNonMippedProxyFromBitmap(SkBitmap const&, SkBackingFit, SkBudgeted)::$_0>, GrSurfaceProxy::LazyCallbackResult (GrResourceProvider*, GrSurfaceProxy::LazySurfaceDesc const&)>::operator()(GrResourceProvider*&&, GrSurfaceProxy::LazySurfaceDesc const&)
0x00000001079a3908(Flutter -functional:1860)GrSurfaceProxyPriv::doLazyInstantiation(GrResourceProvider*)
0x00000001079859d0(Flutter -GrProxyProvider.cpp:306)GrProxyProvider::createProxyFromBitmap(SkBitmap const&, GrMipmapped, SkBackingFit, SkBudgeted)
0x0000000107a28c28(Flutter -SkGr.cpp:161)make_bmp_proxy(GrProxyProvider*, SkBitmap const&, GrColorType, GrMipmapped, SkBackingFit, SkBudgeted)
0x0000000107a28e04(Flutter -SkGr.cpp:244)GrMakeUncachedBitmapProxyView(GrRecordingContext*, SkBitmap const&, GrMipmapped, SkBackingFit, SkBudgeted)
0x000000010798fb00(Flutter -GrSWMaskHelper.cpp:158)GrSWMaskHelper::toTextureView(GrRecordingContext*, SkBackingFit)
0x0000000107991070(Flutter -GrSoftwarePathRenderer.cpp:365)GrSoftwarePathRenderer::onDrawPath(GrPathRenderer::DrawPathArgs const&)
0x000000010799cf90(Flutter -GrPathRenderer.cpp:67)GrSurfaceDrawContext::drawShapeUsingPathRenderer(GrClip const*, GrPaint&&, GrAA, SkMatrix const&, GrStyledShape&&, bool)
0x00000001079a05fc(Flutter -GrSurfaceDrawContext.cpp:1536)GrSurfaceDrawContext::drawShape(GrClip const*, GrPaint&&, GrAA, SkMatrix const&, GrStyledShape&&)
0x00000001079a03c0(Flutter -GrSurfaceDrawContext.cpp:1513)GrSurfaceDrawContext::drawPath(GrClip const*, GrPaint&&, GrAA, SkMatrix const&, SkPath const&, GrStyle const&)
0x0000000107a22bb0(Flutter -SkGpuDevice.cpp:684)SkGpuDevice::drawPath(SkPath const&, SkPaint const&, bool)
0x000000010783d05c(Flutter -SkCanvas.cpp:2037)SkCanvas::onDrawPath(SkPath const&, SkPaint const&)
0x0000000107843310(Flutter -SkCanvas.cpp:1742)SkCanvas::drawPath(SkPath const&, SkPaint const&)
0x00000001078de310(Flutter -SkRecord.h:42)SkBigPicture::playback(SkCanvas*, SkPicture::AbortCallback*) const
0x000000010783df9c(Flutter -SkCanvas.cpp:2534)SkCanvas::onDrawPicture(SkPicture const*, SkMatrix const*, SkPaint const*)
0x00000001078443d8(Flutter -SkCanvas.cpp:2523)SkCanvas::drawPicture(SkPicture const*, SkMatrix const*, SkPaint const*)
0x00000001078de310(Flutter -SkRecord.h:42)SkBigPicture::playback(SkCanvas*, SkPicture::AbortCallback*) const
0x0000000107b228dc(Flutter -picture_layer.cc:151)flutter::PictureLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b1ec60(Flutter -clip_rect_layer.cc:80)flutter::ClipRectLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b1ec60(Flutter -clip_rect_layer.cc:80)flutter::ClipRectLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b21ab0(Flutter -physical_shape_layer.cc:119)flutter::PhysicalShapeLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b232b0(Flutter -transform_layer.cc:96)flutter::TransformLayer::Paint(flutter::Layer::PaintContext&) const
0x0000000107b1f478(Flutter -container_layer.cc:186)flutter::ContainerLayer::PaintChildren(flutter::Layer::PaintContext&) const
0x0000000107b1d6b8(Flutter -layer_tree.cc:110)flutter::CompositorContext::ScopedFrame::Raster(flutter::LayerTree&, bool)
0x0000000107b2bec4(Flutter -rasterizer.cc:491)flutter::Rasterizer::DrawToSurface(fml::TimeDelta, flutter::LayerTree&)
0x0000000107b2cca8(Flutter -rasterizer.cc:365)std::__1::__function::__func<flutter::Rasterizer::Draw(std::__1::unique_ptr<flutter::FrameTimingsRecorder, std::__1::default_delete<flutter::FrameTimingsRecorder> >, std::__1::shared_ptr<flutter::Pipeline<flutter::LayerTree> >, std::__1::function<bool (flutter::LayerTree&)>)::$_2, std::__1::allocator<flutter::Rasterizer::Draw(std::__1::unique_ptr<flutter::FrameTimingsRecorder, std::__1::default_delete<flutter::FrameTimingsRecorder> >, std::__1::shared_ptr<flutter::Pipeline<flutter::LayerTree> >, std::__1::function<bool (flutter::LayerTree&)>)::$_2>, void (std::__1::unique_ptr<flutter::LayerTree, std::__1::default_delete<flutter::LayerTree> >)>::operator()(std::__1::unique_ptr<flutter::LayerTree, std::__1::default_delete<flutter::LayerTree> >&&)
0x0000000107b2c2ec(Flutter -functional:1860)flutter::Rasterizer::Draw(std::__1::unique_ptr<flutter::FrameTimingsRecorder, std::__1::default_delete<flutter::FrameTimingsRecorder> >, std::__1::shared_ptr<flutter::Pipeline<flutter::LayerTree> >, std::__1::function<bool (flutter::LayerTree&)>)
0x0000000107b340c0(Flutter -shell.cc:1163)std::__1::__function::__func<fml::internal::CopyableLambda<flutter::Shell::OnAnimatorDraw(std::__1::shared_ptr<flutter::Pipeline<flutter::LayerTree> >, std::__1::unique_ptr<flutter::FrameTimingsRecorder, std::__1::default_delete<flutter::FrameTimingsRecorder> >)::$_14>, std::__1::allocator<fml::internal::CopyableLambda<flutter::Shell::OnAnimatorDraw(std::__1::shared_ptr<flutter::Pipeline<flutter::LayerTree> >, std::__1::unique_ptr<flutter::FrameTimingsRecorder, std::__1::default_delete<flutter::FrameTimingsRecorder> >)::$_14> >, void ()>::operator()()
0x0000000107acc538(Flutter -functional:1860)fml::MessageLoopImpl::FlushTasks(fml::FlushType)
0x0000000107acf1c0(Flutter -message_loop_impl.cc:143)fml::MessageLoopDarwin::OnTimerFire(__CFRunLoopTimer*, fml::MessageLoopDarwin*)
0x00000001a1f151d0(CoreFoundation + 0x000a41d0)__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
0x00000001a1f14dcc(CoreFoundation + 0x000a3dcc)__CFRunLoopDoTimer
0x00000001a1f1421c(CoreFoundation + 0x000a321c)__CFRunLoopDoTimers
0x00000001a1f0dfd0(CoreFoundation + 0x0009cfd0)__CFRunLoopRun
0x00000001a1f0d304(CoreFoundation + 0x0009c304)CFRunLoopRunSpecific
0x0000000107acf09c(Flutter -message_loop_darwin.mm:46)fml::MessageLoopDarwin::Run()
0x0000000107ace9ac(Flutter -message_loop_impl.cc:96)void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, fml::Thread::Thread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)::$_0> >(void*)
0x00000001edc08bf8(libsystem_pthread.dylib + 0x00001bf8)_pthread_start

#69102 wasn't fixed: "Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now."
Assuming that the assert is the same one (trying to create an encoder when an existing encoder is still active) logically this should not happen unless something on another thread is creating an encoder on that command buffer. I'll look again and see if there's another way the state could get out of sync.
I can also try wrapping the BlitCommandEncoder in a helper object, like we do with the RenderCommandEncoder.

Ah, sorry. It's possible that I had https://github.com/flutter/flutter/issues/69102 confused with https://github.com/flutter/flutter/issues/79313, for which @gaaclarke had a possible fix in https://github.com/flutter/engine/pull/24503.

@xster has been assigned on the internal issue to narrow down the roll CL. Another thing we will need is the logs prior to the crash as these sorts of assertion failures usually log the reason for the failure clearly. Or, a reduced test case.

I think this is not an issue that was fixed by @gaaclarke  before. We also encountered this problem.
Thread 22 Crashed:
0   libsystem_kernel.dylib          0x00000001d83367b0 __pthread_kill
1   libsystem_c.dylib               0x00000001b51b0a44 _abort
2   libGFXShared.dylib              0x00000001dde7438c _gfxAllocateTextureLevel
3   GLEngine                        0x00000001ddda2578 0x00000001ddd90000 + 75128
4   OpenGLES                        0x00000001dde5b8a0 _glTexSubImage2D
5   Flutter                         0x00000001088960c4 GrGLGpu::uploadTexData(SkISize, unsigned int, SkIRect, unsigned int, unsigned int, unsigned long, GrMipLevel const*, int) GrGLFunctions.h
6   Flutter                         0x0000000108895f44 GrGLGpu::uploadColorTypeTexData(GrGLFormat, GrColorType, SkISize, unsigned int, SkIRect, GrColorType, GrMipLevel const*, int) GrGLGpu.cpp
7   Flutter                         0x00000001087c18d0 GrGpu::writePixels(GrSurface*, int, int, int, int, GrColorType, GrColorType, GrMipLevel const*, int, bool) GrGpu.cpp
8   Flutter                         0x00000001087c6e84 std::__1::__function::__func<GrOpFlushState::doUpload(std::__1::function<void ()(std::__1::function<bool ()(GrTextureProxy*, int, int, int, int, GrColorType, void const*, unsigned long)>&)>&, bool)::$_0, std::__1::allocator<GrOpFlushState::doUpload(std::__1::function<void ()(std::__1::function<bool ()(GrTextureProxy*, int, int, int, int, GrColorType, void const*, unsigned long)>&)>&, bool)::$_0>, bool ()(GrTextureProxy*, int, int, int, int, GrColorType, void const*, unsigned long)>::operator()(GrTextureProxy*&&, int&&, int&&, int&&, int&&, GrColorType&&, void const*&&, unsigned long&&) GrGpu.h
9   Flutter                         0x00000001087b9ca8 std::__1::function<bool ()(GrTextureProxy*, int, int, int, int, GrColorType, void const*, unsigned long)>::operator()(GrTextureProxy*, int, int, int, int, GrColorType, void const*, unsigned long) const functional
10  Flutter                         0x00000001087b9c2c GrDrawOpAtlas::Plot::uploadToTexture(std::__1::function<bool ()(GrTextureProxy*, int, int, int, int, GrColorType, void const*, unsigned long)>&, GrTextureProxy*) GrDrawOpAtlas.cpp
11  Flutter                         0x00000001087c6b1c GrOpFlushState::doUpload(std::__1::function<void ()(std::__1::function<bool ()(GrTextureProxy*, int, int, int, int, GrColorType, void const*, unsigned long)>&)>&, bool) functional
12  Flutter                         0x00000001087c6aac GrOpFlushState::preExecuteDraws() GrOpFlushState.cpp
13  Flutter                         0x00000001087bc03c GrDrawingManager::flush(GrSurfaceProxy**, int, SkSurface::BackendSurfaceAccess, GrFlushInfo const&, GrBackendSurfaceMutableState const*) GrDrawingManager.cpp
14  Flutter                         0x00000001087bc470 GrDrawingManager::flushSurfaces(GrSurfaceProxy**, int, SkSurface::BackendSurfaceAccess, GrFlushInfo const&, GrBackendSurfaceMutableState const*) GrDrawingManager.cpp
15  Flutter                         0x00000001087e71b8 GrSurfaceContext::flush(SkSurface::BackendSurfaceAccess, GrFlushInfo const&, GrBackendSurfaceMutableState const*) GrDrawingManager.h
16  Flutter                         0x000000010885b124 SkGpuDevice::flush() SkGpuDevice.cpp
17  Flutter                         0x0000000108a5b69c std::__1::__function::__func<flutter::GPUSurfaceGL::AcquireFrame(SkISize const&)::$_1, std::__1::allocator<flutter::GPUSurfaceGL::AcquireFrame(SkISize const&)::$_1>, bool ()(flutter::SurfaceFrame const&, SkCanvas*)>::operator()(flutter::SurfaceFrame const&, SkCanvas*&&) SkCanvas.cpp
18  Flutter                         0x0000000108697af0 flutter::SurfaceFrame::Submit() functional
19  Flutter                         0x00000001088f49a4 flutter::Rasterizer::DrawToSurface(flutter::LayerTree&) rasterizer.cc
20  Flutter                         0x00000001088f5420 std::__1::__function::__func<flutter::Rasterizer::Draw(fml::RefPtr<flutter::Pipeline<flutter::LayerTree> >)::$_1, std::__1::allocator<flutter::Rasterizer::Draw(fml::RefPtr<flutter::Pipeline<flutter::LayerTree> >)::$_1>, void ()(std::__1::unique_ptr<flutter::LayerTree, std::__1::default_delete<flutter::LayerTree> >)>::operator()(std::__1::unique_ptr<flutter::LayerTree, std::__1::default_delete<flutter::LayerTree> >&&) rasterizer.cc
21  Flutter                         0x00000001088f4c3c flutter::Rasterizer::Draw(fml::RefPtr<flutter::Pipeline<flutter::LayerTree> >) functional
22  Flutter                         0x00000001088fb13c std::__1::__function::__func<flutter::Shell::OnAnimatorDraw(fml::RefPtr<flutter::Pipeline<flutter::LayerTree> >, fml::TimePoint)::$_30, std::__1::allocator<flutter::Shell::OnAnimatorDraw(fml::RefPtr<flutter::Pipeline<flutter::LayerTree> >, fml::TimePoint)::$_30>, void ()()>::operator()() shell.cc
23  Flutter                         0x000000010864625c fml::MessageLoopImpl::FlushTasks(fml::FlushType) functional
24  Flutter                         0x00000001086481d0 fml::MessageLoopDarwin::OnTimerFire(__CFRunLoopTimer*, fml::MessageLoopDarwin*) message_loop_impl.cc
25  CoreFoundation                  0x00000001ac50c0f0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
26  CoreFoundation                  0x00000001ac50bcf0 __CFRunLoopDoTimer
27  CoreFoundation                  0x00000001ac50b1c4 __CFRunLoopDoTimers
28  CoreFoundation                  0x00000001ac5054fc __CFRunLoopRun
29  CoreFoundation                  0x00000001ac504818 _CFRunLoopRunSpecific
30  Flutter                         0x00000001086480ac fml::MessageLoopDarwin::Run() message_loop_darwin.mm
31  Flutter                         0x0000000108647a34 _ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEZN3fml6ThreadC1ERKNS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEE3$_0EEEEEPvSJ_ message_loop_impl.cc
32  libsystem_pthread.dylib         0x00000001f49d7c74 _pthread_start
33  libsystem_pthread.dylib         0x00000001f49dc878 _thread_start

We customized the engine based on version 1.22.6, mainly changes is following：

Change Metal to OpenGLES
Cherry pick the two commits
https://github.com/flutter/engine/pull/24503
https://github.com/flutter/engine/pull/24958

In my opinion, these two changes have nothing to do with this issue
[✓] Flutter (Channel stable/v1.22.6.xianyu, 1.22.6-xianyu, on macOS 11.1 20C69 darwin-x64, locale
    zh-Hans-CN)
    • Flutter version 1.22.6-xianyu at /Users/haoan/Develop/flutter1_22_6xianyu/flutter
    • Framework revision b89ccdd24a (5 days ago), 2021-08-12 17:08:29 +0800
    • Engine revision 9b5590e979
    • Dart version 2.10.5
    • Flutter download mirror http://flutter-storage.alibaba-inc.com/xianyu

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at /Users/haoan/Library/Android/sdk
    • Platform android-S, build-tools 30.0.1
    • ANDROID_HOME = /Users/haoan/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.5)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5, Build version 12E262
    • CocoaPods version 1.10.2

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin installed
    • Dart plugin version 193.7547
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[!] IntelliJ IDEA Community Edition (version 2017.3.3)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • For information about installing plugins, see
      https://flutter.dev/intellij-setup/#installing-the-plugins

[✓] VS Code (version 1.57.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.25.0

[✓] Connected device (1 available)
    • ELS AN00 (mobile) • UQG5T20413009690 • android-arm64 • Android 10 (API 29)

! Doctor found issues in 1 category.

I think the reason for this problem is that DrawToSurface does not use gpu_disable_sync_switch

From the downstream issue. This started appearing in crash logging at flutter/flutter hash a217ab601ad6e8e4d6582ac6ed573c4d101f85e1, which corresponds to engine hash b1385c0df12549b9dce7ce3fee361bd4898f49ae.

I don't think what @ColdPaleLight mentioned is the same issue in the description (maybe that's what they were saying?).  They both stem from DrawToSurface being called.  In my experience I've seen that when you use Metal from the background, you don't crash, it just spits out warnings.  OpenGL however crashes.
To me it looks like another manifestation of https://github.com/flutter/flutter/issues/69102 like Jim said.  I investigated it in the past and couldn't come up with a plausible explanation without reproduction steps.

I think the reason for this problem is that DrawToSurface does not use gpu_disable_sync_switch

I don't know that we want to use sync switch at such a high level as DrawToSurface.  @ColdPaleLight has done a great job identifying new places we need it and supplying CPU fallbacks.  That's the approach we decided upon many moons ago.

Hi, @gaaclarke
Here is my opinion.

I don't think what @ColdPaleLight mentioned is the same issue in the description (maybe that's what they were saying?). They both stem from DrawToSurface being called.

These are indeed two different stack traces. But I think the reasons for the two are the same. DrawToSurface method accessed the GPU in the background（For Metal, a more accurate expression is that app try to encode new command buffer when in the background）.

In my experience I've seen that when you use Metal from the background, you don't crash, it just spits out warnings. OpenGL however crashes.

According to this document from Apple：https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background?language=objc
When your app transitions to the background，you should :

Ensure that all Metal command buffers have been scheduled. For more information, see Preparing Your Metal App to Run in the Background.
Ensure that all OpenGL commands you previously submitted have finished.

So for OpenGL, all commands must be flushed. but for Metal, you only need to ensure that all Metal command buffers have been scheduled.I understand this is what you said Metal will not crash when accessing the GPU in the background.
However, after your app moves into the background, if your app try to encode a new command buffer, it will crash. For example, in this stack https://github.com/flutter/flutter/issues/89171#issue-982920112, the reason for crash is that the app wants to create a IOGPUMetalCommandEncoder  and set it as current command encoder by method [IOGPUMetalCommandBuffer setCurrentCommandEncoder:] when it is in the background.
0x00000001d0185334(libsystem_kernel.dylib + 0x00029334)__pthread_kill
0x00000001edc09a98(libsystem_pthread.dylib + 0x00002a98)pthread_kill
0x00000001ab361b80(libsystem_c.dylib + 0x00077b80)abort
0x00000001b823e2dc(Metal + 0x000982dc)MTLReleaseAssertionFailure
0x00000001df7cb44c(IOGPU + 0x0000344c)-[IOGPUMetalCommandBuffer setCurrentCommandEncoder:]
0x00000001b822e25c(Metal + 0x0008825c)-[_MTLCommandEncoder initWithCommandBuffer:]
0x00000001df7cd108(IOGPU + 0x00005108)-[IOGPUMetalCommandEncoder initWithCommandBuffer:]
0x00000001ef2e7640(AGXMetalA13 + 0x002e7640)
0x00000001ef01ad0c(AGXMetalA13 + 0x0001ad0c)
0x0000000107a665cc(Flutter -GrMtlCommandBuffer.mm:46)GrMtlCommandBuffer::getBlitCommandEncoder()

Here is code line caused crash in Skia: https://github.com/google/skia/blob/1f193df9b393d50da39570dab77a0bb5d28ec8ef/src/gpu/mtl/GrMtlCommandBuffer.mm#L46
Here is ducument about blitCommandEncoder : https://developer.apple.com/documentation/metal/mtlcommandbuffer/1443001-blitcommandencoder
How to resolve it
First of all, we can be sure that when the application is in the background, it should not be allowed to call DrawToSurface.

I don't know that we want to use sync switch at such a high level as DrawToSurface.

Note that the application is in the background at this time, so this frame is actually not visible to the user, so I think we can just discard it directly. We can refer to this code and use gpu_disable_sync_switch there：
https://github.com/flutter/engine/blob/e4a8d23f448ed4c732f27e1cc760717b3a7bf63c/shell/common/rasterizer.cc#L172.
When the user returns to the foreground, the Animator::Start method will go to call RequestFrame to ensure that the latest frame is displayed on the screen

Hi, @gaaclarke
I have filed a draft PR to fix it : https://github.com/flutter/engine/pull/28383
Any thoughts about this?

Thanks for the details @ColdPaleLight.  After reading it I think your hypothesis is plausible.  Even if it doesn't solve the above issue, we agree that it solves a real issue.
I'm still not certain about the proposed fix though.  If possible I'd like more surgical usage of the sync switch.  Unfortunately given the Skia abstraction it might not be possible.  If that is the case though, this will probably not just be a problem for Flutter but for any client of Skia on iOS and we might want to solve it from Skia.
I'll spend some time looking into this today to see if I can propose an alternative / communicate with the Skia team if necessary.

(Reassigned per discussion in triage meeting.)

@ColdPaleLight have you been able to reproduce this crash locally?

Unfortunately, I did not reproduce this crash, but I did some investigations on this crash, I hope it helps.

After searching for the keyword "MTLReleaseAssertionFailure" in Flutter's Issue database, we can see several issues. I believe their root causes are the same.

In these issues, some users reported that the app crashed when the app was in the background.
https://github.com/flutter/flutter/issues/80446
https://github.com/flutter/flutter/issues/74386#issuecomment-824537177  The user said that he reproduced a similar Crash when the App went to the background

So I still suspect that this crash is related to the app going to the background. And based on user feedback, I suspect it is related to Apple's background modes, https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/about_the_background_execution_sequence?language=objc

But I tried to use Metal in the background and it didn’t crash. In fact, I’m not sure if using Metal in the background might crash on a specific iOS version.

I am looking at whether it is related to this PR https://github.com/flutter/engine/pull/25196 . For example, when the user starts the app in background modes (for example, the geographic location changes causing the application to be launched), whether the code in this PR can work normally. But at present I have not found any evidence to support my speculation

Our App will be upgraded to flutter in the near future, and will also switch from OpenGLES to Metal. I believe that our App will encounter the same problem at that time, and I will continue to follow up.

A speculative fix (or at least one that makes the any potential issues more apparent) landed in https://skia-review.googlesource.com/c/skia/+/467357. I suppose the next steps are to wait for this to percolate through the rolls (the patch landed on Nov 04, 2021) and get updated numbers. In the meantime, we can keep an eye out for a reproduction.

The patch has rolled out. But, since it was speculative, I'm keeping this issue open at a lower priority.

Hi, @chinmaygarde @zanderso
Does skia's patch solve the problem of internal users?
Here a similar issue appeared in flutter 2.8 version https://github.com/flutter/flutter/issues/96207

@chinmaygarde @zanderso @gaaclarke
At the same time, I found some guys tweak the code in this way. https://github.com/yx-mike/engine/commit/efac5b57e9fa7e0f1aebda374d92ae65024b7160
And they added a comment in Chinese:  It is not enough that just check if the state is UIApplicationStateBackground, there will also have a small amount of crashes, it should also check if the status is UIApplicationStateInactive.

The Skia change rolled into Flutter at https://github.com/flutter/flutter/commit/4172c7dc005e18c7faec1ea0108cbb4de85ad4a8, which was included in the 2.9 beta, but wasn't included in the 2.8 stable.
@chinmaygarde @gaaclarke ptal at the diff in https://github.com/flutter/flutter/issues/89171#issuecomment-1007542478

We originally blocked the GPU when we were inactive but that lead to bugs where if you scrolled the screen then hit the home button or got a phone call it would stop rendering.  I went through testing that change and it is my understanding from that work that we should have access to the GPU when the app is inactive.

After apply ColdPaleLight's patch,  num of this issue seems came down, but there is some left.  I went through function submitCommandBuffer which located in GrMtlGpu.mm.  Keep using fCurrentCmdBuffer when fCurrentCmdBuffer->commit return false.  I doubt problem is getBlitCommandEncoder from CommandBuffer which has commit failed.

The issue continues to occur in Flutter version 2.10, although it has decreased considerably.

From b/197827241
This appears to be different from #88884 since I don't see any references to MultiFrameCodec in the backtrace.  Is it fixed in 3.0?

Hello, I encounter the same issue, iOS 15.6.1. Cannot reproduce, but can see in crashlytics that it happened
stack_trace.txt

 stack trace
# Crashlytics - Stack trace
# Application: com.otto.application
# Platform: apple
# Version: 1.27.0 (2)
# Issue: 15413151d812cefcb3623fad8ab7e15b
# Session: f6a22eb0114f4c03ae2c12b1c008cebb_DNE_1_v2
# Date: Sat Dec 03 2022 13:21:47 GMT+0200 (Eastern European Standard Time)
com.apple.main-thread
0  libsystem_kernel.dylib         0x14a0 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x1ae4 mach_msg + 76
2  CoreFoundation                 0x6d30 __CFRunLoopServiceMachPort + 372
3  CoreFoundation                 0xb1bc __CFRunLoopRun + 1180
4  CoreFoundation                 0x1ebc8 CFRunLoopRunSpecific + 600
5  GraphicsServices               0x1374 GSEventRunModal + 164
6  UIKitCore                      0x514b58 -[UIApplication _run] + 1100
7  UIKitCore                      0x296090 UIApplicationMain + 364
8  OttoWilde                      0x652c main + 7 (AppDelegate.swift:7)
9  ???                            0x105a29da4 (Missing)
Thread
0  libsystem_kernel.dylib         0x1a74 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1108 _pthread_wqthread + 364
2  libsystem_pthread.dylib        0xe5c start_wqthread + 8
Thread
0  libsystem_kernel.dylib         0x1a74 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1108 _pthread_wqthread + 364
2  libsystem_pthread.dylib        0xe5c start_wqthread + 8
com.apple.uikit.eventfetch-thread
0  libsystem_kernel.dylib         0x14a0 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x1ae4 mach_msg + 76
2  CoreFoundation                 0x6d30 __CFRunLoopServiceMachPort + 372
3  CoreFoundation                 0xb1bc __CFRunLoopRun + 1180
4  CoreFoundation                 0x1ebc8 CFRunLoopRunSpecific + 600
5  Foundation                     0x19444 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 236
6  Foundation                     0x5ae0c -[NSRunLoop(NSRunLoop) runUntilDate:] + 92
7  UIKitCore                      0x48ecc4 -[UIEventFetcher threadMain] + 524
8  Foundation                     0x6941c NSThread__start + 808
9  libsystem_pthread.dylib        0x19ac _pthread_start + 148
10 libsystem_pthread.dylib        0xe68 thread_start + 8
Thread
0  libsystem_kernel.dylib         0x1a74 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1108 _pthread_wqthread + 364
2  libsystem_pthread.dylib        0xe5c start_wqthread + 8
io.flutter.1.ui
0  libsystem_kernel.dylib         0x14a0 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x1ae4 mach_msg + 76
2  CoreFoundation                 0x6d30 __CFRunLoopServiceMachPort + 372
3  CoreFoundation                 0xb1bc __CFRunLoopRun + 1180
4  CoreFoundation                 0x1ebc8 CFRunLoopRunSpecific + 600
5  Flutter                        0x2f90cc (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
6  Flutter                        0x2f8acc (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
7  libsystem_pthread.dylib        0x19ac _pthread_start + 148
8  libsystem_pthread.dylib        0xe68 thread_start + 8
Crashed: io.flutter.1.raster
0  libobjc.A.dylib                0x3180 objc_release + 16
1  Metal                          0x140ec -[_MTLCommandBuffer dealloc] + 56
2  IOGPU                          0x3a08 -[IOGPUMetalCommandBuffer dealloc] + 160
3  AGXMetalA12                    0x33f80 (Missing UUID ffc881206b083889beb28f51e9f3bc08)
4  libobjc.A.dylib                0x7b14 AutoreleasePoolPage::releaseUntil(objc_object**) + 196
5  libobjc.A.dylib                0x3e54 objc_autoreleasePoolPop + 212
6  CoreFoundation                 0xae678 CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION + 32
7  CoreFoundation                 0x32654 __CFRunLoopDoTimer + 1064
8  CoreFoundation                 0x2ce00 __CFRunLoopDoTimers + 320
9  CoreFoundation                 0xb4b0 __CFRunLoopRun + 1936
10 CoreFoundation                 0x1ebc8 CFRunLoopRunSpecific + 600
11 Flutter                        0x2f90cc (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
12 Flutter                        0x2f8acc (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
13 libsystem_pthread.dylib        0x19ac _pthread_start + 148
14 libsystem_pthread.dylib        0xe68 thread_start + 8
io.flutter.1.io
0  libsystem_kernel.dylib         0x14a0 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x1ae4 mach_msg + 76
2  CoreFoundation                 0x6d30 __CFRunLoopServiceMachPort + 372
3  CoreFoundation                 0xb1bc __CFRunLoopRun + 1180
4  CoreFoundation                 0x1ebc8 CFRunLoopRunSpecific + 600
5  Flutter                        0x2f90cc (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
6  Flutter                        0x2f8acc (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
7  libsystem_pthread.dylib        0x19ac _pthread_start + 148
8  libsystem_pthread.dylib        0xe68 thread_start + 8
io.worker.1
0  libsystem_kernel.dylib         0x1f24 __psynch_cvwait + 8
1  libsystem_pthread.dylib        0x8298 _pthread_cond_wait + 1236
2  libc++.1.dylib                 0xd28c std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3  Flutter                        0x2f3840 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
4  libsystem_pthread.dylib        0x19ac _pthread_start + 148
5  libsystem_pthread.dylib        0xe68 thread_start + 8
io.worker.2
0  libsystem_kernel.dylib         0x1f24 __psynch_cvwait + 8
1  libsystem_pthread.dylib        0x8298 _pthread_cond_wait + 1236
2  libc++.1.dylib                 0xd28c std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3  Flutter                        0x2f3840 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
4  libsystem_pthread.dylib        0x19ac _pthread_start + 148
5  libsystem_pthread.dylib        0xe68 thread_start + 8
io.worker.3
0  libsystem_kernel.dylib         0x1f24 __psynch_cvwait + 8
1  libsystem_pthread.dylib        0x8298 _pthread_cond_wait + 1236
2  libc++.1.dylib                 0xd28c std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3  Flutter                        0x2f3840 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
4  libsystem_pthread.dylib        0x19ac _pthread_start + 148
5  libsystem_pthread.dylib        0xe68 thread_start + 8
io.worker.4
0  libsystem_kernel.dylib         0x1f24 __psynch_cvwait + 8
1  libsystem_pthread.dylib        0x8298 _pthread_cond_wait + 1236
2  libc++.1.dylib                 0xd28c std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3  Flutter                        0x2f3840 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
4  libsystem_pthread.dylib        0x19ac _pthread_start + 148
5  libsystem_pthread.dylib        0xe68 thread_start + 8
io.worker.5
0  libsystem_kernel.dylib         0x1f24 __psynch_cvwait + 8
1  libsystem_pthread.dylib        0x8298 _pthread_cond_wait + 1236
2  libc++.1.dylib                 0xd28c std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3  Flutter                        0x2f3840 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
4  libsystem_pthread.dylib        0x19ac _pthread_start + 148
5  libsystem_pthread.dylib        0xe68 thread_start + 8
io.worker.6
0  libsystem_kernel.dylib         0x1f24 __psynch_cvwait + 8
1  libsystem_pthread.dylib        0x8298 _pthread_cond_wait + 1236
2  libc++.1.dylib                 0xd28c std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
3  Flutter                        0x2f3840 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
4  libsystem_pthread.dylib        0x19ac _pthread_start + 148
5  libsystem_pthread.dylib        0xe68 thread_start + 8
dart:io EventHandler
0  libsystem_kernel.dylib         0x2e18 kevent + 8
1  Flutter                        0x4e432c (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
2  Flutter                        0x513414 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
3  libsystem_pthread.dylib        0x19ac _pthread_start + 148
4  libsystem_pthread.dylib        0xe68 thread_start + 8
Thread
0  libsystem_kernel.dylib         0x1a74 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1108 _pthread_wqthread + 364
2  libsystem_pthread.dylib        0xe5c start_wqthread + 8
com.google.firebase.crashlytics.MachExceptionServer
0  FirebaseCrashlytics            0x222ec FIRCLSProcessRecordAllThreads + 184
1  FirebaseCrashlytics            0x226cc FIRCLSProcessRecordAllThreads + 1176
2  FirebaseCrashlytics            0x1869c FIRCLSHandler + 48
3  FirebaseCrashlytics            0x1b248 FIRCLSMachExceptionServer + 688
4  libsystem_pthread.dylib        0x19ac _pthread_start + 148
5  libsystem_pthread.dylib        0xe68 thread_start + 8
Thread
0  libsystem_pthread.dylib        0xe54 start_wqthread + 254
Thread
0  libsystem_kernel.dylib         0x1a74 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1108 _pthread_wqthread + 364
2  libsystem_pthread.dylib        0xe5c start_wqthread + 8
Thread
0  libsystem_pthread.dylib        0xe54 start_wqthread + 254
AVAudioSession Notify Thread
0  libsystem_kernel.dylib         0x14a0 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x1ae4 mach_msg + 76
2  CoreFoundation                 0x6d30 __CFRunLoopServiceMachPort + 372
3  CoreFoundation                 0xb1bc __CFRunLoopRun + 1180
4  CoreFoundation                 0x1ebc8 CFRunLoopRunSpecific + 600
5  AudioSession                   0x6f04 CADeprecated::GenericRunLoopThread::Entry(void*) + 164
6  AudioSession                   0x108f0 CADeprecated::CAPThread::Entry(CADeprecated::CAPThread*) + 92
7  libsystem_pthread.dylib        0x19ac _pthread_start + 148
8  libsystem_pthread.dylib        0xe68 thread_start + 8
com.apple.NSURLConnectionLoader
0  libsystem_kernel.dylib         0x14a0 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x1ae4 mach_msg + 76
2  CoreFoundation                 0x6d30 __CFRunLoopServiceMachPort + 372
3  CoreFoundation                 0xb1bc __CFRunLoopRun + 1180
4  CoreFoundation                 0x1ebc8 CFRunLoopRunSpecific + 600
5  CFNetwork                      0x2781dc _CFURLStorageSessionDisableCache + 60032
6  Foundation                     0x6941c NSThread__start + 808
7  libsystem_pthread.dylib        0x19ac _pthread_start + 148
8  libsystem_pthread.dylib        0xe68 thread_start + 8
DartWorker
0  libsystem_kernel.dylib         0x1f24 __psynch_cvwait + 8
1  libsystem_pthread.dylib        0x82c4 _pthread_cond_wait + 1280
2  Flutter                        0x62a8fc (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
3  Flutter                        0x66b9a0 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
4  Flutter                        0x62a224 (Missing UUID 4aeaca1fde2f3daeb5830cf99fcf86e3)
5  libsystem_pthread.dylib        0x19ac _pthread_start + 148
6  libsystem_pthread.dylib        0xe68 thread_start + 8

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.7, on macOS 12.6.1 21G217 darwin-x64, locale en-UA)
[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 14.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.2)
[✓] Android Studio (version 2021.2)
[✓] VS Code (version 1.73.1)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

• No issues found!

Same issue here.

@mrRedSun Eyeballing the backtraces, your crash looks different than the one that this issue is about. This issue is also referring to a much older version of Flutter. I'm going to close this issue, and ask that you file a new issue with full details so that we can properly triage it. Thanks!


[CPDLP-3131] Add participant id changes table

Context
Ticket: CPDLP-3131
We will need to add the participant id changes table to surface the correct structure in the participants npq endpoint in the API.
Changes proposed in this pull request
Add participant id changes table with correct fields/validations.

Looks good.
A couple of questions.
I'm slightly confused about how we use/surface this data, and does tracking the entire history of changes introduce querying complexity?
i.e. if a participant's changed more than once to get all their previous ids we'd need a recursive query:
flowchart TD
    123 --> 234
    234 --> 345

Like here, 345 used to be both 123 and 234.
Would we be at a disadvantage if we just saved the former_participant_ids in an array?
Participant:
  id: 345
  former_ids: [123, 234]

Do we need to know when the changes happened?

i.e. if a participant's changed more than once to get all their previous ids we'd need a recursive query

We link everything to the current user, so we just have to look at the current user and list the participant id changes
object.participant_id_changes

Would we be at a disadvantage if we just saved the former_participant_ids in an array?

We do surface the changed_at in serialisers so we can't lose that data unfortunately

Ok - I missed that but that means we have 3 foreign keys on participant_id_changes pointing at the users.id, and two end with participant_id.
It wasn't clear to me what they meant and there's no other mention of 'participant' in the database.

Should it be user_id_changes?
Good question, I think we went with the participant in the name as it maps identically to what's in the API and avoids confusion for us.


Helm charts

Pull Request Checklist
Please leverage this checklist as a reminder to address commonly occurring feedback when submitting a pull request to make sure your PR can be reviewed quickly:
See the detailed list in the contributing guide.

[ ] C++ Guidelines
[ ] Doxygen docs
[ ] Unit tests
[ ] No unwanted commits/changes
[ ] Descriptive title/description

[ ] PR is single purpose
[ ] Related issue listed

[ ] Comments in source
[ ] No typos
[ ] Update changelog
[ ] Not work-in-progress
[ ] External references or docs updated
[ ] Self review of PR done
[ ] Any breaking changes?

/azp run cpp - keyvault

/azp run cpp - core

/azp run cpp - core

/azp run cpp - keyvault

/azp run cpp - core

/azp run cpp - core

/azp run cpp - core

/azp run cpp - core

/azp run cpp - core

/azp run cpp - core

@larryosterman

/azp run cpp - core

/azp run cpp - core


crypto/rsa: TLS requests are 2-3x slower in go1.20 with race detection enabled

What version of Go are you using (go version)?

$ go version

go version devel go1.20-bb0d8297d7 Mon Nov 28 19:38:37 2022 +0000 linux/amd64
and
go version devel go1.20-bb0d8297d7 Mon Nov 28 19:38:37 2022 +0000 darwin/arm64

Does this issue reproduce with the latest release?
No, introduced in go1.20 dev branch in https://go-review.googlesource.com/c/go/+/326012
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/liggitt/.cache/go-build"
GOENV="/usr/local/google/home/liggitt/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/usr/local/google/home/liggitt/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/local/google/home/liggitt/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/google/home/liggitt/git/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/google/home/liggitt/git/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.20-bb0d8297d7 Mon Nov 28 19:38:37 2022 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1952584495=/tmp/go-build -gno-record-gcc-switches"
and
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/liggitt/Library/Caches/go-build"
GOENV="/Users/liggitt/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/liggitt/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/liggitt/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/liggitt/git/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/liggitt/git/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="devel go1.20-bb0d8297d7 Mon Nov 28 19:38:37 2022 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/37/ns7gt60104scfm9fvg02p1jh00kjgb/T/go-build3981291129=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Ran project unit tests making TLS requests with race detection enabled (xref https://github.com/kubernetes/kubernetes/issues/114145#issuecomment-1330378146)
Minimal reproducer:
package main

import (
	"net/http"
	"net/http/httptest"
	"strings"
	"testing"
	"time"
)

func TestRequest(t *testing.T) {
	transport, req := setup(t)
	start := time.Now()
	do(t, transport, req)
	t.Log(time.Since(start))
}

func BenchmarkRequest(b *testing.B) {
	transport, req := setup(b)
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		do(b, transport, req)
	}
}

func setup(t testing.TB) (*http.Transport, *http.Request) {
	data := []byte(strings.Repeat("a", 1024*1024)) // 1kb of data
	server := httptest.NewTLSServer(http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) { w.Write(data) }))
	t.Cleanup(server.Close)

	transport := server.Client().Transport.(*http.Transport).Clone()
	transport.DisableKeepAlives = true // dial every time

	req, err := http.NewRequest("GET", server.URL, nil)
	if err != nil {
		t.Fatal(err)
	}

	return transport, req
}

func do(t testing.TB, transport *http.Transport, req *http.Request) {
	resp, err := transport.RoundTrip(req)
	if err != nil {
		t.Fatal(err)
	}
	defer resp.Body.Close()
	if resp.StatusCode != 200 {
		t.Fatal("unexpected status")
	}
}

run with
$go1.19.3 test main_test.go -race -bench . -count=20 > 1.19.3-race.txt
$go1.19.3 test main_test.go -bench . -count=20 > 1.19.3-norace.txt
$gotip test main_test.go -race -bench . -count=20 > head-race.txt
$gotip test main_test.go -bench . -count=20 > head-norace.txt
benchstat 1.19.3-race.txt head-race.txt
benchstat 1.19.3-norace.txt head-norace.txt

What did you expect to see?
TLS request times are roughly equivalent to go1.19 regardless of race detection.
What did you see instead?
to make the same request as with go1.19, go1.20 takes ~2x longer on linux/amd64, ~3x longer on darwin/arm64, and even longer on linux/ppc64le (I'm working on getting numbers with the minimal reproducer above)
linux/amd64:
name        old time/op  new time/op   delta
Request-24  8.92ms ± 3%  16.82ms ± 1%  +88.45%  (p=0.000 n=20+20)

darwin/arm64
name        old time/op  new time/op   delta
Request-10  9.32ms ± 5%  30.26ms ± 1%  +224.58%  (p=0.000 n=19+18)

This is with a simple request that only has the client verifying the server cert. When more is involved (mutual TLS or an RSA JWT verification), the slowdown is even more pronounced (3x - 7x slowdowns observed in https://github.com/kubernetes/kubernetes/issues/114145).
Without race detection, the slowdown due to https://go-review.googlesource.com/c/go/+/326012 was not as drastic, but was still milliseconds longer per request:
linux/amd64:
name        old time/op  new time/op  delta
Request-24  3.18ms ± 3%  4.02ms ± 3%  +26.58%  (p=0.000 n=19+19)

darwin/arm64
name        old time/op  new time/op  delta
Request-10  5.68ms ± 8%  7.72ms ±31%  +35.90%  (p=0.000 n=20+20)

cc @FiloSottile

cc @laboger @archanaravindar

Thank you for the details! If I understand the benchmark correctly, both the server and the client side of the handshake contribute to the benchmarked time, so this is observing an RSA-2048 sign+verify cycle. In that case +26% on amd64 and +35% on arm64 is more or less in line with the benchmarks we had.
I had not benchmarked with the race detector enabled, and it's interesting the performance profile is so different. I can look into it, but it would help to understand if race detector-enabled performance is a goal. The Go 1.20 changes are a tradeoff that knowingly sacrifice a bit of performance for a lot of security by cutting a large chunk of attack surface (math/big).
In the meantime, if you just want your tests to be faster (assuming that's where the race detector matters), you might consider using a smaller (insecure) RSA key, or checking if ECDSA keys perform better.

https://go-review.git.corp.google.com/c/go/+/326012

(Please use https://go.dev/cl/ links, these links don't work outside Google. There's an internal Chrome extension you can use to easily copy a shortened version of the link to the current page. Thank you!)

Please use https://go.dev/cl/ links, these links don't work outside Google. There's an internal Chrome extension you can use to easily copy a shortened version of the link to the current page

yeah, already fixed, sorry about that

In that case +26% on amd64 and +35% on arm64 is more or less in line with the benchmarks we had.

It wasn't clear to me that the benchmarks in http://go.dev/cl/326012 represented known multi-millisecond slowdowns for requests (where both the client and server performance is impacted in serial). The CL also alluded to possible optimizations ("this is without any assembly at all, and that further improvements are likely possible"), and I was surprised to see it merge without attempting to preserve status quo for performance.

it would help to understand if race detector-enabled performance is a goal

It's not specifically a goal, but the change turned several of our tests that were previously solid green (taking ~30ms to make a request with a 100ms timeout) into mostly-failing flakes (taking 200ms+ to make the same request) on some architectures.
As we are working to be able to update Kubernetes release branches to new go minor versions with minimal code changes, knowing this is in the pipeline and anticipating chasing down new test flakes and backporting test changes to release branches as a result of a go version bump is a red flag.

In that case +26% on amd64 and +35% on arm64 is more or less in line with the benchmarks we had.

It wasn't clear to me that the benchmarks in http://go.dev/cl/326012 represented known multi-millisecond slowdowns for requests (where both the client and server performance is impacted in serial). The CL also alluded to possible optimizations ("this is without any assembly at all, and that further improvements are likely possible"), and I was surprised to see it merge without attempting to preserve status quo for performance. Are any of those improvements planned before go1.20 freezes?

Go 1.20 already froze. We landed https://go.dev/cl/445019, https://go.dev/cl/445020, https://go.dev/cl/445021, and https://go.dev/cl/452095 to reduce the performance gap. https://go.dev/cl/452095 has the final benchmarks on amd64 compared to Go 1.19, which amount to 500µs for sign+verify on the Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz I ran them on, which is more or less in line with the 840µs you're seeing. We do have extra optimization work planned for Go 1.21, and the new backend can in theory become faster than the old one with the same amount of assembly.
When you say multi-millisecond slowdowns, I assume you mean with the race detector enabled. That's interesting and worth looking into (it might be an issue in the race detector or in the interaction, maybe?) but the question is whether race detector-enabled performance is a blocker worth reverting the security improvement over.

 The race detector instrumentation only gets inserted in Go code.
I don't think race detector performance should be a release blocker.

When you say multi-millisecond slowdowns, I assume you mean with the race detector enabled

No, without race detection, a dial+handshake+request takes at least a millisecond longer, and in some architectures, multiple milliseconds longer. That reflects real runtime impact, which I was surprised by.

I don't think race detector performance should be a release blocker.

I tend to agree (pain of backporting deflaking test changes notwithstanding), but I was surprised by the degree of the performance drop, and wanted to surface what we saw in case it indicated a bigger problem.

and even longer on linux/ppc64le (I'm working on getting numbers with the minimal reproducer above)

@liggitt
linux/ppc64le:
name       old time/op  new time/op   delta
Request-8  33.3ms ±17%  136.4ms ± 5%  +309.28%  (p=0.000 n=18+16)

Have run your Minimal reproducer in description.
[root@raji-workspace ~]# go1.19.3 version
go version go1.19.3 linux/ppc64le
[root@raji-workspace ~]# gotip version
go version devel go1.20-78472603c6 Tue Nov 29 22:59:16 2022 +0000 linux/ppc64le
[root@raji-workspace ~]# go1.19.3 test main_test.go -race -bench . -count=20 > 1.19.3-race.txt
[root@raji-workspace ~]# go1.19.3 test main_test.go -bench . -count=20 > 1.19.3-norace.txt
[root@raji-workspace ~]# gotip test main_test.go -race -bench . -count=20 > head-race.txt
[root@raji-workspace ~]# gotip test main_test.go -bench . -count=20 > head-norace.txt
[root@raji-workspace ~]#  benchstat 1.19.3-race.txt head-race.txt
name       old time/op  new time/op   delta
Request-8  33.3ms ±17%  136.4ms ± 5%  +309.28%  (p=0.000 n=18+16)
[root@raji-workspace ~]#


Your ATLAS server exec could not be found

Hey everyone! First off thank you so much for all the support here. I'm running Ubuntu 20.04.5, and going through the quick start guide, I keep getting this error when I run the atlasmanager install command.
atlasmanager install
[  WARN  ] 	Your ATLAS server exec could not be found.
[  ERROR  ] 	You have not rights to write in the log directory.
Running command 'install' for instance 'main'
[  ERROR  ] 	You have not rights to write in the log directory.
Installing ATLAS server ...
Would love to get this working. I've made sure everything is up to date, but still no dice.
Thanks,
Max

In testing, I have gotten the same error. I will see if this is a quick fix and post an update with any changes.