Half Life 2 mod Neotokyo crashes after map load

This will probably be noise since the game is very obscure and abandoned, but hopefully will be useful somehow.
Neotokyo runs fine on some maps, but other maps crash the game as reported here. The game crashes during map load.
I'm using Valve's Proton 4.11, with PROTON_USE_D9VK=1. Without it the game runs fine, albeit not as good as D9VK, and with some minor graphical glitches (as mentioned in the topic above) most likely due to something related to this although disabling this workaround doesn't change anything in wineD3D anyway (the "fog" glitch).
Haven't tested with latest commits in master.

Before the next step, make sure you disable or get rid of D9VK files first, as it's preferred that you use WineD3D to make an apitrace.

The game doesn't crash with WineD3D, only with D9VK. I can't generate an apitrace by using Valve's Proton 4.11 with launch parameter PROTON_USE_WINED3D=1, because the game wouldn't crash.
The apitrace below has been generated with D9VK active in Proton 4.11, so it's probably useless? Sorry about that.
Software information
Game: hl2.exe NeotokyoSource mod
Settings: launch option in Steam client: PROTON_LOG=1 PROTON_USE_D9VK=1 %command% -console +voice_loopback 1 -nojoy
System information

GPU: GTX 670MX
Driver: nvidia 430.40
Wine version: 4.11 ?
DXVK version:  0b21ef187aa50d97e1f0fa4f02fc47d0a63c5c5f dxvk (v1.3.2-4-g0b21ef18) ?
D9VK version:  1c5ce36e36d87a7160b47675153406bbe68f02f3 d9vk (v0.90-1653-g1c5ce36e) ?
Proton:<PHONE_NUMBER> proton-4.11-2

Apitrace file(s)

hl2.trace.tar.xz See below for a trace without d9vk.

Log files

hl2_d3d9.log
d3d11.log: none
hl2_dxgi.log

Here an apitrace of hl2.exe crashing consistently after loading a map (nt_redlight_ctg) with  PROTON_USE_WINED3D=1. link

The game crashes when graphics settings in game are the default ones. This might be an issue on Windows too, so you should probably disregard that one.
Here is another trace where graphics settings are set to lower texture quality.
Model detail: from High -> Medium
Texture details: from High -> Medium
Shader detail: from High -> Low
Water detail: from Reflect World -> Simple Reflections
Apparently, setting Texture Detail to high is what crashes consistently, even on Windows. So this is most likely not related to d9vk nor Wine at all.
In that trace, I immediately went back to the main menu after loading and rendering the map correctly, then exited the game. The game did not crash link

Thanks for the clear report, I will look into this.
Source games are always fairly straight forward to debug.

I wasn't able to replicate this in the game myself.
Possibly a Wine bug?

Thanks for having looked into this.
I had not thought it would be related to WINE since the game only crashes with d9vk and not wined3d. Or perhaps it's an issue with Vulkan and the GPU driver? Although that sounds unlikely because an AMD GPU user is experiencing the same type of crash with d9vk (Linux also).
Would you recommend a way to investigate this further?
I suppose I'll have to report to the WINE project eventually but I'm not really sure what to report.
Also not really sure that the DxvkMemoryAllocator error is really what crashes the game, considering there is no report of any exception thrown (see this dxvk issue for example). Maybe I should report to DXVK?

I've managed to work around the crash by adding the launch parameter PROTON_FORCE_LARGE_ADDRESS_AWARE=1 which "Forces Wine to enable the LARGE_ADDRESS_AWARE flag for all executables." according to the documentation.
However, the game is a hitching a lot in some areas (mostly the main street in nt_redlight_ctg), and I got this repeated error "Too many vertex format changes in frame, whole world not rendered" in the hl2 console. Not sure if it's related.

I've experienced Too many vertex format changes in frame, whole world not rendered in Source when developing Blade Symphony. Pretty sure D9VK can't cause that.

You're right, I got a bit carried away. this is definitely not related to the renderer. Edited the post to redact that.
Didn't realize you were part of the Blade Symphony team, congrats on releasing such a nice game. Impressive work. I like Puny Human's games. :)

I wasn't part of the team when it started -- I just did the Winter [2017? maybe? or maybe it was 2018] and Harmonious Prelude update.

With Proton 4.11-3, the infamous fog glitch (which also happens with regular wined3d) has suddenly appeared in D9VK! I thought we would be safe, but no.

with fog_override = 1 (and sv_cheats 1), we get the preferred rendering:

The dxgi.nvapiHack = False in dxvk.conf doesn't fix it either. (the line DXGI: NvAPI workaround enabled, reporting AMD GPU is not printed to the dxgi log which confirms the config is applied)
However this is a cheat convar which means we can't use it in multiplayer servers. Since fog_override seems to render things correctly, I think we can rule out a faulty graphics driver.
hl2_dxgi.log and hl2_d3d9.log
Is there a way to look for that with apitrace?
Still not sure what part of the Source engine handles this fog shader thing.
This happens in Windows too on some hardware (and drivers), both nVidia and AMD. Nobody could find what exactly is the root of the problem though. It happens consistently under Wine, although it didn't happen with the previous version of Proton and D9VK (that was d9vk-v0.90-1653-g1c5ce36e)

I'll take a look at what the game is doing tomorrow. Thanks for bringing this to my attention. Should be an ez fix given it's a Source game :)

Fog looks fine to me... Exactly the same as native.

Also the crash is not my bug, it happens on native d3d9 too.

Closing this as it isn't my bug.


[RESOLVED] High ICMP ping response time

Problem started at 13:51:29 on 2023.04.19
Problem name: High ICMP ping response time
Host: HP_iLO
Severity: Warning
Operational data: Value: 756ms
Original problem ID: 19767
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23268&eventid=19767

Problem has been resolved in 6m 0s at 13:57:29 on 2023.04.19
Problem name: High ICMP ping response time
Host: HP_iLO
Severity: Warning
Original problem ID: 19767


Benchmark pruning old backups

I think this is an important use case

Agreed

Agreed too, but I need more than synthetic benchmarks to do this.
I am planning to use this backup script to backup my lab VMs for a month or so, and I may add a prune benchmark then once I have "real data" repositories with big changes between files.
Also, some of the programs like kopia already do the house cleaning and implement GFS, so that would be more difficult to benchmark.


Create Flatpak

It would be very convenient for Linux users if a Flatpak version of the program was made.

This would be neat for sure, however I don't have a Linux machine. If someone knows the build process for this, reach out to me on the discord, and I can help you make a workflow file for the CI to build this.


build: CMake: set OUTPUT_NAME for uv_a

It is not clear to me really why there cannot be just a single "uv"
library, which could be driven through BUILD_SHARED_LIBS to be shared
(by default), or static.
This change therefore provides to be a minimal fix, resulting in an
output of libuv.a, instead of libuv_a.a.

/cc @bnoordhuis (via https://github.com/libuv/libuv/commit/7e6681f733629cec91116dab8f9e72059e00e91e)

This is included in https://github.com/libuv/libuv/pull/2085 already kind of.. :/

Note that luv uses "uv_a" explicitly already: https://github.com/luvit/luv/blob/8a04eeb719223de4f4ab07391bfab9b45b17be7d/CMakeLists.txt#L72 (via https://github.com/luvit/luv/commit/9e6dd83ef480a174858f0443a31cc67ba060f041).  /cc @creationix

It is not clear to me really why there cannot be just a single "uv"

One of the goals of the current CMakeLists.txt is to test both shared and static library builds simultaneously (hence the uv_run_tests and uv_run_tests_a targets.)
I don't think there's a reliable way of doing that without giving the targets different names but I don't mind being proven wrong. ^^
The fact that there already some users of the uv_a target also makes me lean towards maintaining the status quo. Thanks anyway for the pull request!


Bash Completion for python based commands (Ansible)

Describe the bug
The argument completer does not find the correct completion for python based commands.
To Reproduce
Steps to reproduce the behavior:
apt install ansible
apt install python3-argcomplete
Test functionality in wsl, e.g.
ansible-playbook --a
this results in
ansible-playbook --ask
Leave wsl and create the command in PowerShell:
Import-WslCommand ansible-playbook
Expected behavior
Getting the same result in PowerShell, but
ansible-playbook --a
results in
ansible-playbook --a
So nothing happens.
Additional context
The behavior is clear, if I query the following in PowerShell
$global:WslCompletionFunctions
I can see that the value for ansible-playbook is "_minimal".
So basically the problem is in line 126 of WslInterop.psm1:
$global:WslCompletionFunctions[$command] = wsl.exe bash -c ". /usr/share/bash-completion/bash_completion 2> /dev/null; __load_completion $command 2> /dev/null; complete -p $command 2> /dev/null | sed -E 's/^complete.-F ([^ ]+).`$/\1/'"
My bash knowledge is way too low to fix this.
Do you have any idea how to fix this or at least what I can manually set by:
$global:WslCompletionFunctions["ansible-playbook"] = "???"
Thx for your great module, I enjoy it almost every day, but this would improve my work even a little more.

Just a quick update, meanwhile I figured out, how to solve the problem manually:
$global:WslCompletionFunctions["ansible-playbook"] = '_python_argcomplete_global "ansible-playbook"'
When I execute this, the tab completion works as expected in PowerShell.
Of course it would be nice, if the module could figure this out by itself, but as said my knowledge about bash is very low. Maybe this helps

Thanks for filing. I'll take a look.

I don't seem to get completions within WSL. I tried with both WSL 1 and WSL 2. I installed ansible and python3-argcomplete. Am I missing something else?

You are almost there. You need ansible and python3-argcomplete.
Then you need to run:
sudo activate-global-python-argcomplete3

Thanks. I see what's happening here. activate-global-python-argcomplete3 is overriding bash's default completion function rather than assigning a completion function to each command.
I'll need to think through how to potentially handle this.

Could you try out the latest changes in the master branch? Just overwrite your copy of (gmo WslInterop).Path with the latest version.
You'll need to clear your WslCompletionFunctions cache by running "ri $Env:APPDATA\PowerShell WSL Interop\WslCompletionFunctions" and then restarting PowerShell.

I did a small test and it looks good. A little bit strange to see "-D" in the output of the completion functions, but it works. Personally I would have used a specific variable like WslCompletionLoader, but from a user perspective it works.
(Speaking of variables, maybe it is a good idea to initialize the WslDefaultParameterValues as an emtpy hashtable, if it does not already exist while loading the module. I find it always annoying to check if it exists before I can add a value. It has nothing to do with this topic,.)

I did a small test and it looks good.

Excellent.

(Speaking of variables, maybe it is a good idea to initialize the WslDefaultParameterValues as an emtpy hashtable, if it does not already exist while loading the module. I find it always annoying to check if it exists before I can add a value. It has nothing to do with this topic,.)

I wanted to keep the global session state clean unless you use a feature, and I'd expect if you're reusing your preferred defaults, you would initialize the hash table in your profile.


Spanish translation

Full translation into Spanish

Hi @eliluminado
You also need to add the language on the optionsframe.py module as mentioned in the build section of the HOWTO.
https://github.com/MrS0m30n3/youtube-dl-gui/blob/master/youtube_dl_gui/optionsframe.py#L1396

@eliluminado
I'm closing this pull request.
Now a spanish translation is available.
See: pull-request-46 for more info.


appcode-eap-custom-jdk

fix for #879

And why it's not merged?

@sebroeder Is this in line with the unification you’re working on?

@vitorgalvao this cask as well as the appcode-eap cask are very rough (they even have the version number hard-coded in the download url). I am working on them now.

Done in #1070 (thank you anyway, @yurikoles, but @sebroeder is working hard to fix these all).


Exception in realm::SharedGroup::BadVersion

Hi, what this error message means?
Realm version: 0.98.6 and 0.98.5
Xcode version: 7.3
iOS/OSX version: 8 and newer

This is an internal error, you shouldn't be able to trigger as far as I can tell. Can you reproduce this exception? If so, could you provide us the stack trace and sample code to do that, so that we are able to determine the underlying cause?

I am getting this error occasionally. I am still trying to figure out when it occurs and what changes that I've made, cause it. Usually my last log shows a successful insert operation. After that I am getting exception with nowhere to point out. If I get more information, I will share with you. In the meantime I will send crashlytics report to your email.

We'll need more information, ideally steps to reproduce, in order to make progress on this.

This has happened to me immediately after running a migration. Sadly I was not lucid enough to capture the full stack trace. I have quite a few notification observes in my app that I register fairly early. For some reason I feel like these things are linked but I can't really say why.

First screenshot is when the exception is thrown, the second is at the time of crash.

From the backtrace it looks like RealmCoordinator::advance_to_ready is trying to "advance" to an older version. @tgoyne, any ideas?

Hi, I am ocasinally getting the same error.
Realm version: 0.98.6
Xcode version: 7.3
iOS/OSX version: 8 and newer
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   Zinomax                         0x00000001001f20b8 0x100094000 + 1433784 (_mh_execute_header + 1433784)
1   Zinomax                         0x0000000100155d1c 0x100094000 + 793884 (_mh_execute_header + 793884)
2   Zinomax                         0x000000010014c8a4 0x100094000 + 755876 (_mh_execute_header + 755876)
3   CoreFoundation                  0x0000000183594efc 0x1834b8000 + 904956 ( + 24)
4   CoreFoundation                  0x0000000183594990 0x1834b8000 + 903568 ( + 540)
5   CoreFoundation                  0x0000000183592690 0x1834b8000 + 894608 ( + 724)
6   CoreFoundation                  0x00000001834c1680 0x1834b8000 + 38528 (CFRunLoopRunSpecific + 384)
7   GraphicsServices                0x00000001849d0088 0x1849c4000 + 49288 (GSEventRunModal + 180)
8   UIKit                           0x0000000188338d90 0x1882bc000 + 511376 (UIApplicationMain + 204)
9   Zinomax                         0x00000001000df2b8 0x100094000 + 307896 (_mh_execute_header + 307896)
10  libdyld.dylib                   0x00000001830628b8 0x183060000 + 10424 ( + 4)

@palatov: Thanks for reporting that. Do you have any more information to share when the crash happens for you and what you're doing at that moment in your app? If you can reproduce it yourself and could share a sample project with us (confidentially to help@realm.io), that would be vastly helpful for our further investigations.

I got the same exception;
I am using v0.98.8 in ObjC;
* thread #1: tid = 0xec3a80, 0x0000000107c29c6b libc++abi.dylib`__cxa_throw, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
    frame #0: 0x0000000107c29c6b libc++abi.dylib`__cxa_throw
  * frame #1: 0x0000000102af341c houseqm`void realm::SharedGroup::advance_read<(anonymous namespace)::TransactLogValidator>(this=0x00007fe0b9852e00, observer=0x00007fff5d5dfde8, version_id=(version = 95, index = 25))::TransactLogValidator*, realm::SharedGroup::VersionID) + 220 at group_shared.hpp:924
    frame #2: 0x0000000102af332b houseqm`void realm::_impl::SharedGroupFriend::advance_read<(anonymous namespace)::TransactLogValidator>(sg=0x00007fe0b9852e00, obs=0x00007fff5d5dfde8, ver=(version = 95, index = 25))::TransactLogValidator*, realm::SharedGroup::VersionID) + 59 at group_shared.hpp:1097
    frame #3: 0x0000000102af32db houseqm`void realm::LangBindHelper::advance_read<(anonymous namespace)::TransactLogValidator>(sg=0x00007fe0b9852e00, observer=0x00007fff5d5dfde8, version=(version = 95, index = 25))::TransactLogValidator&&, realm::SharedGroup::VersionID) + 59 at lang_bind_helper.hpp:352
    frame #4: 0x0000000102af3205 houseqm`auto realm::_impl::transaction::advance(this=0x00007fff5d5dfdd8, args=0x00007fff5d5dfde8)::$_0::operator()<(anonymous namespace)::TransactLogValidator&>((anonymous namespace)::TransactLogValidator&&&) const + 69 at transact_log_handler.cpp:438
    frame #5: 0x0000000102af2e42 houseqm`(anonymous namespace)::TransactLogObserver::TransactLogObserver<realm::_impl::transaction::advance(this=0x00007fff5d5dfde8, context=0x00007fe0bb0eafe0, sg=0x00007fe0b9852e00, func=0x00007fff5d5dfdd8, validate_schema_changes=true)::$_0>(realm::BindingContext*, realm::SharedGroup&, realm::_impl::transaction::advance(realm::SharedGroup&, realm::BindingContext*, realm::SharedGroup::VersionID)::$_0&&, bool) + 1106 at transact_log_handler.cpp:222
    frame #6: 0x0000000102af25de houseqm`(anonymous namespace)::TransactLogObserver::TransactLogObserver<realm::_impl::transaction::advance(this=0x00007fff5d5dfde8, context=0x00007fe0bb0eafe0, sg=0x00007fe0b9852e00, func=0x00007fff5d5dfdd8, validate_schema_changes=true)::$_0>(realm::BindingContext*, realm::SharedGroup&, realm::_impl::transaction::advance(realm::SharedGroup&, realm::BindingContext*, realm::SharedGroup::VersionID)::$_0&&, bool) + 62 at transact_log_handler.cpp:204
    frame #7: 0x0000000102af258a houseqm`realm::_impl::transaction::advance(sg=0x00007fe0b9852e00, context=0x00007fe0bb0eafe0, version=(version = 95, index = 25)) + 90 at transact_log_handler.cpp:437
    frame #8: 0x0000000102944816 houseqm`realm::_impl::RealmCoordinator::advance_to_ready(this=0x00007fe0bb039dd0, realm=0x00007fe0b8c7d7a0) + 966 at realm_coordinator.cpp:438
    frame #9: 0x0000000102aec639 houseqm`realm::Realm::notify(this=0x00007fe0b8c7d7a0) + 329 at shared_realm.cpp:381
    frame #10: 0x000000010291873f houseqm`realm::_impl::CachedRealm::CachedRealm(this=0x00000001029186d0, info=0x00007fe0b8ddf580)::$_0::operator()(void*) const + 79 at cached_realm.cpp:38
    frame #11: 0x00000001029186e8 houseqm`realm::_impl::CachedRealm::CachedRealm(info=0x00007fe0b8ddf580)::$_0::__invoke(void*) + 24 at cached_realm.cpp:36
    frame #12: 0x0000000103b5a301 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    frame #13: 0x0000000103b5022c CoreFoundation`__CFRunLoopDoSources0 + 556
    frame #14: 0x0000000103b4f6e3 CoreFoundation`__CFRunLoopRun + 867
    frame #15: 0x0000000103b4f0f8 CoreFoundation`CFRunLoopRunSpecific + 488
    frame #16: 0x0000000108f4bad2 GraphicsServices`GSEventRunModal + 161
    frame #17: 0x000000010563df09 UIKit`UIApplicationMain + 171
    frame #18: 0x000000010273425f houseqm`main(argc=7, argv=0x00007fff5d5e1588) + 111 at main.m:14
    frame #19: 0x0000000107d6992d libdyld.dylib`start + 1
    frame #20: 0x0000000107d6992d libdyld.dylib`start + 1

Hi all, I'm sorry you're affected by this issue. We're investigating what may be causing this but unfortunately we don't have much to go on at this point.
Any further information that you can provide that could help us identify what's causing this to happen would be very useful and very appreciated.

Full stack trace. Hoping this will be helpful.
Realm version: 0.98.6
Xcode version: 7.3
iOS/OSX version: 8 and newer
Fatal Exception: realm::LogicError: Bad version number

Crashed: com.twitter.crashlytics.ios.exception
0  My App                     0x1001ad60c CLSProcessRecordAllThreads +<PHONE_NUMBER>
1  My App                     0x1001ad60c CLSProcessRecordAllThreads +<PHONE_NUMBER>
2  My App                     0x1001ada2c CLSProcessRecordAllThreads +<PHONE_NUMBER>
3  My App                     0x10019e8e0 CLSHandler +<PHONE_NUMBER>
4  My App                     0x1001abf30 __CLSExceptionRecord_block_invoke +<PHONE_NUMBER>
5  libdispatch.dylib              0x1822d547c _dispatch_client_callout + 16
6  libdispatch.dylib              0x1822e0728 _dispatch_barrier_sync_f_invoke + 100
7  My App                     0x1001ab9dc CLSExceptionRecord +<PHONE_NUMBER>
8  My App                     0x1001ab560 CLSTerminateHandler() +<PHONE_NUMBER>
9  libc++abi.dylib                0x181ee2f44 std::__terminate(void (*)()) + 16
10 libc++abi.dylib                0x181ee2b10 __cxa_rethrow + 144
11 libobjc.A.dylib                0x181ef0120 objc_exception_rethrow + 44
12 CoreFoundation                 0x182768db8 CFRunLoopRunSpecific + 552
13 GraphicsServices               0x184050088 GSEventRunModal + 180
14 UIKit                          0x187a3df70 UIApplicationMain + 204
15 My App                     0x10015627c main (AppDelegate.swift:17)
16 libdispatch.dylib              0x1823068b8 (Missing)

Thread
0  libsystem_kernel.dylib         0x182424b48 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1824ed530 _pthread_wqthread + 1284
2  libsystem_pthread.dylib        0x1824ed020 start_wqthread + 4

com.apple.libdispatch-manager
0  libsystem_kernel.dylib         0x1824254d8 kevent_qos + 8
1  libdispatch.dylib              0x1822e87d8 _dispatch_mgr_invoke + 232
2  libdispatch.dylib              0x1822d7648 _dispatch_source_invoke + 50

Thread
0  libsystem_kernel.dylib         0x182424b48 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1824ed530 _pthread_wqthread + 1284
2  libsystem_pthread.dylib        0x1824ed020 start_wqthread + 4

// ... several more threads like the above

RLMRealm notification listener
0  libsystem_kernel.dylib         0x18240d528 kevent + 8
1  Realm                          0x10057711c realm::_impl::ExternalCommitHelper::listen() (external_commit_helper.cpp:199)
2  Realm                          0x100577318 std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator()() (future:2331)
3  Realm                          0x1005772a0 std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::__execute() (future:1025)
4  Realm                          0x100577468 std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(void*, void*) (memory:2516)
5  libsystem_pthread.dylib        0x1824efb28 _pthread_body + 156
6  libsystem_pthread.dylib        0x1824efa8c _pthread_body + 154
7  libsystem_pthread.dylib        0x1824ed028 thread_start + 4

com.apple.NSURLConnectionLoader
0  libsystem_kernel.dylib         0x182408fd8 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x182408e54 mach_msg + 72
2  CoreFoundation                 0x182840ce8 __CFRunLoopServiceMachPort + 196
3  CoreFoundation                 0x18283e9ec __CFRunLoopRun + 1032
4  CoreFoundation                 0x182768d10 CFRunLoopRunSpecific + 384
5  CFNetwork                      0x182ee9af4 +[NSURLConnection(Loader) _resourceLoadLoop:] + 412
6  Foundation                     0x18325fe1c __NSThread__start__ + 1000
7  libsystem_pthread.dylib        0x1824efb28 _pthread_body + 156
8  libsystem_pthread.dylib        0x1824efa8c _pthread_body + 154
9  libsystem_pthread.dylib        0x1824ed028 thread_start + 4

NSOperationQueue 0x13eb90310 :: NSOperation 0x13f2986c0 (QOS: LEGACY)
0  libsystem_kernel.dylib         0x18242441c __semwait_signal + 8
1  libsystem_c.dylib              0x18234122c nanosleep + 212
2  libsystem_c.dylib              0x18234114c usleep + 68
3  Starscream                     0x1002ef460 WebSocket.((initStreamsWithData in _E91840E7069A0D2D302D042308E9D928)(NSData, Int) -> ()).(closure #1) (WebSocket.swift:313)
4  Foundation                     0x183244510 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
5  Foundation                     0x183196900 -[NSBlockOperation main] + 96
6  Foundation                     0x183186ed8 -[__NSOperationInternal _start:] + 604
7  Foundation                     0x183246904 __NSOQSchedule_f + 224
8  libdispatch.dylib              0x1822d547c _dispatch_client_callout + 16
9  libdispatch.dylib              0x1822e14c0 _dispatch_queue_drain + 864
10 libdispatch.dylib              0x1822d8f80 _dispatch_queue_invoke + 464
11 libdispatch.dylib              0x1822e3390 _dispatch_root_queue_drain + 728
12 libdispatch.dylib              0x1822e30b0 _dispatch_worker_thread3 + 112
13 libsystem_pthread.dylib        0x1824ed470 _pthread_wqthread + 1092
14 libsystem_pthread.dylib        0x1824ed020 start_wqthread + 4

I am experiencing it too:
* thread #20: tid = 0x1929, 0x0000000180cb1528 libsystem_kernel.dylib`kevent + 8, name = 'RLMRealm notification listener'
  * frame #0: 0x0000000180cb1528 libsystem_kernel.dylib`kevent + 8
    frame #1: 0x000000010200a9f8 Realm`realm::_impl::ExternalCommitHelper::listen(this=0x000000012e38bb60) + 412 at external_commit_helper.cpp:199
    frame #2: 0x000000010200b5a4 Realm`realm::_impl::ExternalCommitHelper::ExternalCommitHelper(this=0x000000012e3a7170)::$_0::operator()() const + 24 at external_commit_helper.cpp:159
    frame #3: 0x000000010200b580 Realm`_ZNSt3__112__async_funcIZN5realm5_impl20ExternalCommitHelperC1ERNS2_16RealmCoordinatorEE3$_0JEE9__executeIJEEEvNS_15__tuple_indicesIJXspT_EEEE [inlined] std::__1::__invoke<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>(__f=0x000000012e3a7170)::$_0>(fp)(std::__1::forward<>(fp0))), realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0&&) + 64 at __functional_base:416
    frame #4: 0x000000010200b570 Realm`_ZNSt3__112__async_funcIZN5realm5_impl20ExternalCommitHelperC1ERNS2_16RealmCoordinatorEE3$_0JEE9__executeIJEEEvNS_15__tuple_indicesIJXspT_EEEE(this=0x000000012e3a7170, (null)=__tuple_indices<> @ 0x000000016e19ec20) + 48 at future:2338
    frame #5: 0x000000010200b534 Realm`std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator(this=0x000000012e3a7170)() + 24 at future:2331
    frame #6: 0x000000010200b444 Realm`std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::__execute(this=0x000000012e3a70e0) + 32 at future:1025
    frame #7: 0x000000010200bcc8 Realm`std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(void*, void*) [inlined] std::__1::__invoke<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*, void>(__f=0x000000012e374d30, __a0=0x000000012e374d40)::$_0> >*>(fp0)).*fp(std::__1::forward<>(fp1))), void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*&&)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*&&) + 100 at __functional_base:383
    frame #8: 0x000000010200bc64 Realm`std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(void*, void*) [inlined] _ZNSt3__116__thread_executeIMNS_19__async_assoc_stateIvNS_12__async_funcIZN5realm5_impl20ExternalCommitHelperC1ERNS4_16RealmCoordinatorEE3$_0JEEEEEFvvEJPSA_EJLm1EEEEvRNS_5tupleIJT_DpT0_EEENS_15__tuple_indicesIJXspT1_EEEE(__t=0x000000012e374d30) + 40 at thread:337
    frame #9: 0x000000010200bc3c Realm`std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(__vp=0x000000012e374d30) + 248 at thread:347
    frame #10: 0x0000000180d93b28 libsystem_pthread.dylib`_pthread_body + 156
    frame #11: 0x0000000180d93a8c libsystem_pthread.dylib`_pthread_start + 156
    frame #12: 0x0000000180d91028 libsystem_pthread.dylib`thread_start + 4

We've been seeing this as well among our beta users:
Fatal Exception: realm::LogicError: Bad version number

Crashed: com.twitter.crashlytics.ios.exception
0  Workflow                       0x10013b048 CLSProcessRecordAllThreads +<PHONE_NUMBER>
1  Workflow                       0x10013b048 CLSProcessRecordAllThreads +<PHONE_NUMBER>
2  Workflow                       0x10013b468 CLSProcessRecordAllThreads +<PHONE_NUMBER>
3  Workflow                       0x10012c12c CLSHandler +<PHONE_NUMBER>
4  Workflow                       0x100139770 __CLSExceptionRecord_block_invoke +<PHONE_NUMBER>
5  libdispatch.dylib              0x18156d47c _dispatch_client_callout + 16
6  libdispatch.dylib              0x181578728 _dispatch_barrier_sync_f_invoke + 100
7  Workflow                       0x10013921c CLSExceptionRecord +<PHONE_NUMBER>
8  Workflow                       0x100138da0 CLSTerminateHandler() +<PHONE_NUMBER>
9  libc++abi.dylib                0x18117af44 std::__terminate(void (*)()) + 16
10 libc++abi.dylib                0x18117ab10 __cxa_rethrow + 144
11 libobjc.A.dylib                0x181188120 objc_exception_rethrow + 44
12 CoreFoundation                 0x181a00db8 CFRunLoopRunSpecific + 552
13 GraphicsServices               0x1832e8088 GSEventRunModal + 180
14 UIKit                          0x186ccdf70 UIApplicationMain + 204
15 Workflow                       0x10010f78c main (main.m:14)
16 libdispatch.dylib              0x18159e8b8 (Missing)

Crashlytics says the issue does not happen when the app is in focus, and @AriX experienced it after letting the app sit after a while. If I had to guess, it would be NSFileProtectionComplete acting up when the keybag is locked – changing the data out from underneath Realm, perhaps.
We don't seem to be experiencing this in production (0.95.1) but are in beta (0.99.1)

@ptseng can you share a project that triggers the crash? Thanks!

@jpsim I was able to reliably reproduce the crash referenced in #3510, although I am not sure if it is the same crash as this one: boom.zip
Basically: the entire database (the memory mapping) is yanked out from under Realm by file protection and everything breaks (where it blows up depends on what you're doing with the DB at the time).

Thanks for taking the time to craft a repro case @conradev! We'll need to discuss internally to figure out how we can mitigate this, if it's at all possible...

I am not sure if it is the same crash as in this thread.

I actually just experienced the crash with the trace including realm::SharedGroup::advance_read and it occurred when my device was unlocked, but sitting idle for a few minutes. I do think the reproduction case and the issue in this thread are separate.

Wanted to note that I've also separately noticed this crash (with the exception named "Realm::LogicError: bad version") occur on a device that was running our app idle in the foreground for a few minutes.
The issue also appears to be fairly common among our beta testers (we have received many crash reports for this issue) and apparently only began occurring after we upgraded from Realm 0.95.1 to 0.98.6.

Any update?
Actually I got the exception quite often, over 50% my app's crash was occurred by this exception. But when I got the exception, my app is doing lots of heavy reading and write operations in a 'Sync' action, that I
can't simply reproduce the issue. :(

I haven't had any luck with just auditing the code and looking for problems, so it's unlikely that we'll be able to make progress on fixing this without a repro case of some sort.

This is still our number 1 source of crashes. I think the issue is related to accessing a realm on multiple threads at the same time (maybe that's obvious I have no idea).

FWIW I have a strong feeling this bug is caused by running realm.refresh() within a Realm notification block and/or write transaction.

Calling it from within a write transaction is explicitly a no-op, but refreshing from within a notification if there are still more notifications to be delivered could plausibly cause this.

I dug into this a bit more, and while I think calling refresh() from within a notification block should probably be forbidden (it behaves somewhat oddly and is very unlikely to be a useful thing to do), I couldn't find any way to get it to actually break.

Just to be clear, we have yet to identify the root cause here, or find a repro case, so if anyone could share a sample project if they manage to create one, that'd be greatly appreciated, and basically a requirement for us to make progress on this.

Hi guys,
I'm experiencing the same crash once in a while. I'm still investigating what could cause it, our application performs some transactions in a background thread, basically it queries dirty objects and post them to an API endpoint.
I started to get the exception in a more complex view that keeps track of changes in the main UI only. I was using RBQFetchedResultsController for fetching some records, and decided to give it a try only relying on Realm notifications and stopped getting those exceptions. I went back to a view that is still using this extension, RBQFetchedResultsController, and it still happens there.
The exception is always being thrown at this block, but acctually is very difficult to debug for me.
I'm in a middle of a critical deadline so I haven't got the time to set up a project to replicate my situation exactly but I will hopefully be able in a couple of days.

I am able to recreate this pretty reliably in v2.0.1. It seems more frequent than in 1.0.2, but it is hard to say.
I have a background thread that sync objects to a server and then updates realm. This happens in a dedicated dispatch queue. I call [[RLMRealm defaultRealm] refresh] before each iteration through the syncing logic (happens once a second).
There is a UITableView that has a notification block on a RLMResults that is supposed to process the data and update the table.
Sometimes it crashes! Here's a stack trace. Let me know if there is more data I can provide.
Thread 1
Queue : com.apple.main-thread (serial)
#0	0x000000010a308867 in __cxa_throw ()
#1	0x0000000105c953b7 in std::__1::unique_ptr<realm::TableView, std::__1::default_delete<realm::TableView> > realm::SharedGroup::import_from_handover<realm::TableView>(std::__1::unique_ptr<realm::SharedGroup::Handover<realm::TableView>, std::__1::default_delete<realm::SharedGroup::Handover<realm::TableView> > >) at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/core/include/realm/group_shared.hpp:900
#2	0x0000000105c951d7 in realm::_impl::ResultsNotifier::deliver(realm::SharedGroup&) at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/impl/results_notifier.cpp:193
#3	0x0000000105c89d98 in realm::_impl::RealmCoordinator::advance_to_ready(realm::Realm&) at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/impl/realm_coordinator.cpp:585
#4	0x0000000105c7a065 in realm::_impl::WeakRealmNotifier::Callback::operator()() at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/impl/weak_realm_notifier.cpp:40
#5	0x00000001082e9311 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#6	0x00000001082ce59c in __CFRunLoopDoSources0 ()
#7	0x00000001082cda86 in __CFRunLoopRun ()
#8	0x00000001082cd494 in CFRunLoopRunSpecific ()
#9	0x000000010d34da6f in GSEventRunModal ()
#10	0x000000010abb8f34 in UIApplicationMain ()
#11	0x0000000104d92c5f in main at /Users/jesset/projects/crm/CRM-XM/main.m:14
#12	0x000000010aa0c68d in start ()
#13	0x000000010aa0c68d in start ()

Thread 5
com.apple.uikit.eventfetch-thread (6)

Thread 13
Queue : com.apple.root.default-qos.overcommit (concurrent)
#0	0x000000010c95189b in pthread_mutex_unlock ()
#1	0x00000001082f7729 in CFRunLoopSourceInvalidate ()
#2	0x0000000105c7a2da in realm::util::EventLoopSignal<realm::_impl::WeakRealmNotifier::Callback>::~EventLoopSignal() at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/util/apple/event_loop_signal.hpp:58
#3	0x0000000105bcee7e in std::__1::__shared_weak_count::__release_shared() ()
#4	0x0000000105c7a017 in std::__1::shared_ptr<realm::util::EventLoopSignal<realm::_impl::WeakRealmNotifier::Callback> >::~shared_ptr() [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4593
#5	0x0000000105c7a009 in std::__1::shared_ptr<realm::util::EventLoopSignal<realm::_impl::WeakRealmNotifier::Callback> >::~shared_ptr() [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4591
#6	0x0000000105c7a009 in realm::_impl::WeakRealmNotifier::~WeakRealmNotifier() at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/impl/weak_realm_notifier.cpp:35
#7	0x0000000105c8818f in std::__1::allocator<realm::_impl::WeakRealmNotifier>::destroy(realm::_impl::WeakRealmNotifier*) [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:1795
#8	0x0000000105c88187 in void std::__1::allocator_traits<std::__1::allocator<realm::_impl::WeakRealmNotifier> >::__destroy<realm::_impl::WeakRealmNotifier>(std::__1::integral_constant<bool, true>, std::__1::allocator<realm::_impl::WeakRealmNotifier>&, realm::_impl::WeakRealmNotifier*) [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:1668
#9	0x0000000105c88187 in void std::__1::allocator_traits<std::__1::allocator<realm::_impl::WeakRealmNotifier> >::destroy<realm::_impl::WeakRealmNotifier>(std::__1::allocator<realm::_impl::WeakRealmNotifier>&, realm::_impl::WeakRealmNotifier*) [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:1536
#10	0x0000000105c88187 in std::__1::__vector_base<realm::_impl::WeakRealmNotifier, std::__1::allocator<realm::_impl::WeakRealmNotifier> >::__destruct_at_end(realm::_impl::WeakRealmNotifier*) [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:424
#11	0x0000000105c8817e in std::__1::vector<realm::_impl::WeakRealmNotifier, std::__1::allocator<realm::_impl::WeakRealmNotifier> >::__destruct_at_end(realm::_impl::WeakRealmNotifier*) [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:813
#12	0x0000000105c8817e in std::__1::vector<realm::_impl::WeakRealmNotifier, std::__1::allocator<realm::_impl::WeakRealmNotifier> >::erase(std::__1::__wrap_iter<realm::_impl::WeakRealmNotifier const*>, std::__1::__wrap_iter<realm::_impl::WeakRealmNotifier const*>) at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:1696
#13	0x0000000105c88087 in realm::_impl::RealmCoordinator::unregister_realm(realm::Realm*) at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/impl/realm_coordinator.cpp:172
#14	0x0000000105d44693 in realm::Realm::~Realm() at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/shared_realm.cpp:202
#15	0x0000000105bcee7e in std::__1::__shared_weak_count::__release_shared() ()
#16	0x0000000107144a0a in object_cxxDestructFromClass(objc_object*, objc_class*) ()
#17	0x00000001071504de in objc_destructInstance ()
#18	0x0000000107150510 in object_dispose ()
#19	0x0000000105d2a966 in -[RLMRealm dealloc] at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/RLMRealm.mm:520
#20	0x000000010715ab12 in objc_object::sidetable_release(bool) ()
#21	0x000000010715b1d1 in (anonymous namespace)::AutoreleasePoolPage::pop(void*) ()
#22	0x000000010a9a1800 in _dispatch_root_queue_drain ()
#23	0x000000010a9a108b in _dispatch_worker_thread3 ()
#24	0x000000010c953746 in _pthread_wqthread ()
#25	0x000000010c953221 in start_wqthread ()
com.apple.NSURLConnectionLoader (8)Thread 9Thread 10Thread 11Thread 12RLMRealm notification listener (15)#0	0x000000010c91fe2e in kevent ()
#1	0x0000000105c73c6a in realm::_impl::ExternalCommitHelper::listen() at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/impl/apple/external_commit_helper.cpp:199
#2	0x0000000105c7470e in realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0::operator()() const [inlined] at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/ObjectStore/src/impl/apple/external_commit_helper.cpp:159
#3	0x0000000105c74709 in std::__1::__invoke<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>(decltype(std::__1::forward<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>(fp)(std::__1::forward<>(fp0))), realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0&&) [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:416
#4	0x0000000105c74700 in _ZNSt3__112__async_funcIZN5realm5_impl20ExternalCommitHelperC1ERNS2_16RealmCoordinatorEE3$_0JEE9__executeIJEEEvNS_15__tuple_indicesIJXspT_EEEE [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:2348
#5	0x0000000105c74700 in std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator()() at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:2341
#6	0x0000000105c7469a in std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::__execute() at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1031
#7	0x0000000105c74843 in std::__1::__invoke<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*, void>(decltype(*(std::__1::forward<std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*>(fp0)).*fp(std::__1::forward<>(fp1))), void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*&&)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*&&) [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:383
#8	0x0000000105c7482a in _ZNSt3__116__thread_executeIMNS_19__async_assoc_stateIvNS_12__async_funcIZN5realm5_impl20ExternalCommitHelperC1ERNS4_16RealmCoordinatorEE3$_0JEEEEEFvvEJPSA_EJLm1EEEEvRNS_5tupleIJT_DpT0_EEENS_15__tuple_indicesIJXspT1_EEEE [inlined] at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:347
#9	0x0000000105c7482a in std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(void*, void*) at /Applications/Xcode-8.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:357
#10	0x000000010c953abb in _pthread_body ()
#11	0x000000010c953a07 in _pthread_start ()
#12	0x000000010c953231 in thread_start ()

Looks like my issue is fixed in 2.02. I guess it is this release note "Fix a BadVersion error when a background worker finishes running while older results from that worker are being delivered to a different thread."

I'm glad to hear that @asjesset!
Can others on this thread confirm whether or not 2.0.2 also resolved this problem for you?

@jpsim I'm sorry to bring bad news, but we have been seeing this since the upgrade from 1.0.2 to 1.1.0 and above. I have, however, managed to create a sample project reproducing this issue, and I have emailed it to<EMAIL_ADDRESS>In short, the problem (for us) seems to be related to an NSURLSession dispatching the delegate methods on the .mainQueue() if supplied on session creation.
When we then write download progress to Realm in func URLSession(session: NSURLSession, downloadTask: NSURLSessionDownloadTask, didWriteData bytesWritten: Int64...) and at the same time listen for changes via a notification block for a results set on the same queue, the BadVersion error almost* always occurs.
* for one file download it sometimes work, but for two concurrent downloads, it always crashes.
I'm really not sure why this would happen. Perhaps we missed some part of the Realm documentation stating we should not do this the way we do, but hopefully this sample project can help you guys figure out what might render this.

Thanks for reporting and sharing a very good repro case @hermanolsson! We were able to reproduce the race on our end and @tgoyne has already pushed a fix in realm/realm-object-store#195. We'll close this issue once that fix has been included in this repo, at which point it would be useful if you could try it out in your main app where you've been experiencing this problem.

@jpsim do you have any idea about the timeframe for the fix to be merged here? We're having this crash in production and are preparing a fix version. Would love to include this in the fix since it is one of our top issues. Thanks a lot.

@jpsim @tgoyne is there a way to test this? We are seeing this crash a lot right now and I would like to send a version to our beta testers to validate the fix. Thanks.

@kevincador you can test this by building from the jp-update-object-store branch. If you're using CocoaPods, specify the following in your Podfile:
pod 'Realm', git: 'https://github.com/realm/realm-cocoa.git', branch: 'jp-update-object-store', submodules: true
pod 'RealmSwift', git: 'https://github.com/realm/realm-cocoa.git', branch: 'jp-update-object-store', submodules: true

Please reopen if you still see this problem after incorporating realm/realm-object-store#195 into your apps.

Thank you @jpsim ! I have integrated master into our project and I have not seen this crash since. 👍

@jpsim did a lot of testing in local. So far, so good. Will send a new version to our beta testers soon and get back to you asap if we see the issue again.

I confirm we're not seeing this crash anymore (public beta testing). Will send this to production soon.

Is this bug present version 2.0.2? Or there haven't been any new releases recently?

The change from realm/realm-object-store#195 has not yet been included in a release. We're working on getting a release out later this week, as soon as we've updated our infrastructure and release process to produce builds for Swift 3.0.1.

@jpsim We're debating downgrading to 1.0.2 while waiting for this issue to be fixed. Does this sound like a good strategy to you, or would it be better to wait for the update?

Realm 2.0.3 should be out by end of day tomorrow (hopefully earlier).

I experienced the bug in v2.1, but due to it's random nature I really don't know how to help you figure this out...

@pawelkata since your issue appears to be occurring during a migration of a Realm rather than when delivering collection notifications, it's likely to be unrelated to the rest of the discussion in this thread.
However, I'd encourage you to update to the latest version of Realm and open a new issue along with more information if you run into problems. Thanks.

I'll be locking this conversation to make sure future problems are reported as new issues, preventing messages from being missed by our team. Thanks for understanding!


Chat opened with .startChatActivityForID not working properly

List<Thread> threads=NM.thread().getThreads(ThreadType.Private1to1);
                for (Thread thread:
                     threads) {
                    if(thread.hasUser(user1)){
                        InterfaceManager.shared().a.startChatActivityForID(getApplicationContext(),thread.getEntityID());
                        isThreadExists=true;
                        break;
                    }
                }

I have above code in my activity to open chat between 2 users at runtime.
Please find below scenario.
1.On one device chat is opened from chatlist activity
2. On another device chat is opened run time
then
When the message is sent from first device it is not received on second device.
Please help.

@bensmiley Could you check this issue?.I would not able to release my app because of this.


Add the ability to retrieve the modelname of an entity

It would be lovely to be able to retrieve the correct model used by an entity in a specific demo, as an example players using agent skins etc..
something like https://github.com/saul/demofile/blob/d815a88e98698a849326b845c959261a5c7d4d2f/src/entities/baseentity.ts#L68C1-L80

I took a look into stringtables and I think they are not there anymore (in cs2). Entities do seem to have a new field like this:
"CCSPlayerPawn.CBodyComponentBaseAnimGraph.m_hModel = U64(13181005211767972979)
(a field that is decoded as a u64). But how this number should be interpreted i don't know :/

@0xGabrielel I added the prop "agent_skin" to 0.15.0. Is there anything else that could be interesting?

closing issue as it was done: added in ver 0.15.0


CSV parser fails with mixed quoting and non-standard row_sep

opts = {row_sep: "|\n", col_sep: ","}
CSV.parse(CSV.generate(opts) { |csv|
  csv << ["yes, it's true"];
  csv << [ "CSV is broken"];
  csv << ["uhoh!"]; }, opts)

In the example above, the parser will raise a CSV::MalformedCSVError (Unquoted fields do not allow new line <"\n"> in line 2.) error.
It will succeed if any of the following are done:

pass force_quotes: true to generate
add a comma in each row
remove the comma from the first row
use row_sep: "\n"

Therefore, the problem seems to be that a non-standard row_sep + lines with a field being quoted in one row and unquoted in the next.

I'm using the version included in ruby 2.6.5, btw!

The stack trace indicates that it's failing in parse_quotable_robust. I'm thinking the problem may be that in prepare_unquoted, the @unquoted_value regexp does not take into account the value of row_sep. Therefore, the '|' is consumed by the scanner as part of the unquoted field value. After this, the "|\n" no longer exists to denote a line break, and instead the \n is interpreted as the next character of this field.

Why do you want to use "|\n"?
Could you show a real world use case?

We're using this because we're interfacing with other systems that have very poor support for CSV, and get confused by newlines in quoted fields. That said, these files are created and then transformed by our software before being passed off to the other software (various RDBMSes) so during that first, internal phase, we could just use the default row/column separators, and avoid needing to parse the non-standard format.
If you don't want to support it, that's ok but an error should probably be raised when reading with non-standard row/col separators.

Could you show the real CSV that has problem?
The CSV does NOT use "|\n" as row separator, right?

The CSV was using "|\n" as a row separator.
This CSV is used for an export/import process that involves creating CSV files, transforming them, and then finally importing them into MySQL, Postgres, Oracle, etc. We use a "|\n" separator in the final CSV files to overcome very poor CSV support in some of these databases.
It used to be the case that the initial CSV files were written with the "|\n" row separator, which meant that we had to support it when reading the CSV files for the transformation & filtering step. The generated CSV was not any more complicated than what was produced in the initial example I provided.
After discovering this issue, I have modified our system to only use the "|\n" separator in the final step - right before the file is imported into the other SQL databases.

Ah, sorry. I want to know the input of your transformation system. I think that the following is a situation of this case:
X -CSV(X)-> [YOUR SYSTEM] -CSV(RDBMS)-> RDBMS

I want to know a sample content of CSV(X).

The whole process starts with our database, so the situation is more like:

step
system
name
read row_sep
write row_sep

1
ruby (rails)
DB to CSV  (exporting)

"|\n"

2
ruby
CSV to CSV (filtering)
"|\n"
"|\n"

3
ruby
CSV to CSV-like (transforming)
"|\n"
various things, including "|\n"

4
RDBMS
CSV-like to DB
various things, including "|\n"

the data is in our database
we export that data into many CSV files
those CSV files are transformed by removing rows and columns
those CSV files are transformed into an alternate CSV format, depending on what RDBMS they will be loaded into
they're loaded into the RDBMSes

Steps 1-2 happen daily, steps 3,4,5 are repeated many times with the output of steps 1-2.
The system has been modified to now work like this:

step
system
name
read row_sep
write row_sep

1
ruby (rails)
DB to CSV  (exporting)

"\n"

2
ruby
CSV to CSV (filtering)
"\n"
"\n"

3
ruby
CSV to CSV-like (transforming)
"\n"
various things, including "|\n"

4
RDBMS
CSV-like to DB
various things, including "|\n"

With this change, we no longer need to read CSV files with row_sep: "|\n", which means this bug no longer affects us.
The reason we were reading with that row separator is because it is convenient to use the same row separator from start to end of the process. It's OK to have to use standard CSV in steps 1 and 2. The actual data we are processing is not relevant to the process or the usage of that row separator.
Therefore, in my opinion, the main bug is that you can set anything you want as row_sep during reading, but the reader will fail to read files with non-standard row_sep values.

Thanks. I understand.
I'll think about how to deal with this case.


feat: allow passwordless authentification

This PR lets obs-do try to connect to the websocker server even if no token file can be found.
Also, if the connection fails, make sure to warn the user about this.
Fixes #1

Thanks for your review !

Yep, was just doing that as you were typing. Now released as 0.1.1 :)

Yep, was just doing that as you were typing. Now released as 0.1.1 :)

Amazing ! Thanks :)


Update sbt-lucuma to 0.11.3

About this PR
📦 Updates edu.gemini:sbt-lucuma from 0.4.2 to 0.11.3
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "edu.gemini", artifactId = "sbt-lucuma" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "edu.gemini", artifactId = "sbt-lucuma" }
}]

labels: sbt-plugin-update, early-semver-major, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #151.


add support for @Injectable on a dedicated class with @MapperFactory

Support of @Injectable on dedicated class which have at least one method annotated with @MapperFactory has not been investigated. It is unknown whether both annotations are compatible. If not (that would be too bad, though), no compilation error is raised.

[ ] investigate compatibility between @Injectable and @MapperFactory
[ ] implement support with integration tests if compatible, raise a compilation error if not

Note: it is likely that issue #43 must be addressed before this one as it might be required to make compatibility possible

I actually need this :)


Create output file structure for reference visualization app

@ananya-jain1  Request to take a look

@TLSravani  - request you to please provide a description to this issue so that we could resolve the same.

invalid


GEP-1619: Add context on session persistence naming

What type of PR is this?
/kind gep
What this PR does / why we need it:
Add a section "Naming" which outlines our decision for choosing session persistence and session affinity. Also recognize sticky session as a valid alternative name.
Update section about session affinity to include the fact that session affinity CAN use cookies or headers. Also add details about the difference between persistence and affinity across proxy restarts or backend pool change.
Discussion: https://github.com/kubernetes-sigs/gateway-api/discussions/2893
Which issue(s) this PR fixes:
Fixes #
Updates for https://github.com/kubernetes-sigs/gateway-api/issues/1619
Does this PR introduce a user-facing change?:
NONE

This is a great update, nice work @gcs278. Happy to LGTM as-is once it's move out of draft.

/lgtm


pari: 2.13.3 -> 2.13.4

Description of changes
Sage tests pass: https://logs.nix.ci/?attempt_id=204d1fd4-8794-406d-9a49-17f26fced481&key=nixos%2Fnixpkgs.175044
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

@ofborg build sage

Have you seen the build failure on aarch64? Do you know if that is a regression?

Have you seen the build failure on aarch64? Do you know if that is a regression?

Thanks for checking! Assuming you're talking about the aarch64_darwin failure, it's not a regression. It's just that the pari derivation assumes Darwin implies x86_64 because Darwin support was added five years ago. Could be easy to fix but I don't have a machine to test it on.


[Bug]: filter un-necessary global autocomplete items

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
e.g. latLong, dropdownOption, chartData etc...

Steps To Reproduce

Open a JS binding {{}}
type latLong, chartData etc...
These are not entities that should be listed as suggestions.

They are internal types used within widgets. And should be filtered.
Environment
Production
Version
Cloud

Hey, I'm working on Chart docs -- is chartData going to be removed from autocomplete suggestions?
If so, I won't bother documenting the property. Otherwise, I was probably going to open a ticket asking for a cleaner workaround for using it, as currently you have to use something like
{{ Chart1.chartData[Object.keys(Chart1.chartData)[0]].data }}

in order to actually access the series data 😂

@spark-c, this bug only focuses on the global entries. (e.g. chartData)
Not the chartData inside a chart object. (e.g. Chart1.chartData)

Please feel free to join our discord server, we have a dedicated channel for support queries.

AH, thank you! I didn't notice that detail :)


Platform view devicelab ad banner scroll list real ads

Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.
List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] I followed the breaking change policy and added Data Driven Fixes where supported.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@hellohuanlin is this ready for review? Are you blocked on something?

@jonahwilliams I am still trying to solve the infra issue https://mail.google.com/mail/u/0/#inbox/FMfcgzGxRxBHdlmhDPJqVscdMSWxTlbh
But yes the code itself is ready for review.

I can't follow the link you sent, you can @me in the internal chat

If the code is ready for review you need to mark it ready for review and ask someone to review it, otherwise everyone will assume you are still tinkering on it.

@jonahwilliams Sorry i linked wrongly, so here you go: https://github.com/flutter/flutter/pull/144745

If the code is ready for review you need to mark it ready for review and ask someone to review it, otherwise everyone will assume you are still tinkering on it.

Actually I am still tinkering on it, mainly on the infra side tho. The app side (dart code) should be ready.

If you want feedback you should mark as ready for review. Don't wait until its 100% ready

    info • Use 'const' with the constructor to improve performance • dev/benchmarks/platform_views_layout/lib/main_ad_banners.dart:35:17 • prefer_const_constructors
    info • Use a 'SizedBox' to add whitespace to a layout • dev/benchmarks/platform_views_layout/lib/main_ad_banners.dart:54:17 • sized_box_for_whitespace

Reason for revert: appears to have broken the build.

I think we just need to update the gradle lockfiles for the android app


test: add integration test framework for Dragonfly

Signed-off-by: Allen Sun<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
Feature this pr provides is based on https://github.com/alibaba/Dragonfly/pull/222. Only after we support golang server side, the work this pr has done is meaningful.
When we setup a supernode, we should add integration test support for it to guarantee the quality.
I add a very specifc integration test readme in this pr.
Future work to do:

add a Makefile to utilize the test cases;
add integration of test in CI system.

Ⅱ. Does this pull request fix one issue?

none
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
already added.
Ⅳ. Describe how to verify it
First we should start the supernode daemon, then execute the go test command:
test (add-test-framework) $ go test -check.f APIPingSuite.TestPing
OK: 1 passed
PASS
ok      github.com/alibaba/Dragonfly/test       0.058s

Ⅴ. Special notes for reviews

Codecov Report

Merging #225 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #225   +/-   ##
======================================
  Coverage    72.4%   72.4%
======================================
  Files          29      29
  Lines        1435    1435
======================================
  Hits         1039    1039
  Misses        365     365
  Partials       31      31

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 4aa8035...f4a9954. Read the comment docs.

The dead link will be OK if once this PR is merged:
FILE: ./test/README.md
[✖] https://github.com/dragonflyoss/Dragonfly/blob/master/client/client_test.go

ERROR: dead links found!

This PR is ready now. PTAL.


ArgumentError with SingleUpload of MultiPart Request

Describe the bug
I have a question about the multipart request feature and I am trying to implement a single upload. Since there is only information in the documentation about the multi file upload, my first question is whether the single upload, as described in the spec, is already possible. Since I'm currently getting a ArgumentError.
To Reproduce
Currently I have the following code:
String document = '''
mutation singleUpload(\$file: Upload!) {
  singleUpload(file: \$file) {
    filename
  }
}
'''.replaceAll('\n', ' ');

final data = {'file': File(filePath)};
final result = await client.mutate(
  MutationOptions(
    document: document,
    variables: data,
    fetchPolicy: FetchPolicy.networkOnly,
  ),
);

Unfortunately I get the following error [ArgumentError, Invalid argument(s)] with this code.
Expected behavior
I expected the file to be sent correctly to the server. If I print the variables of this operation in the fetchQuery method with
final Operation operation = Operation.fromOptions(options);
print(operation.variables);

I get {file: File: '/data/data/com.example.example.dev/cache/large_database.colpkg'}.
I guess that's where the error is, because instead of 'file': 'path' it says 'file': 'File': 'path'. If I pass the filepath instead of file(filepath), I don't get an ArgumentError and the mutation is successfully sent to the server. But logically the file is missing.
Desktop:

OS: MacOS
Version 10.14.4

Smartphone:
I've tested it on several Android devices.
A big thanks to the developers of this plugin, especially to @truongsinh, for implementing the multipart requests feature. If desired, I could implement a minimal example to reproduce the problem that helps to solve it. I just don't know how I should implement the server.

If I added authentication to the mutation and the error no longer occurred, close the issue.


DB Options Improvements

Add Indirect Checkpoints

Indirect checkpoints were introduced in SQL 2012 and became the default in SQL 2016.  Databases migrated from older SQL version won't automatically be changed.  It would be useful to highlight on the DB Options tab if we have any databases not using indirect checkpoints.  This would be a warning as the feature might not be beneficial in all situations and requires evaluation.  This feature might not be beneficial for tempdb so system DBs could be excluded.
Also, add warning for non-default target recovery time - Considering 0 and 60 as default values.

Add drilldowns

At the summary level, you should be able to click to see which databases have "Page Verify Not Optimal" etc.

Add highlighting to detail level.
Update highlighting for OK/NA

Included in 2.35.0 🚀


Make Access Logs configurable

Issue: #190

Current coverage is 97.28% (diff: 87.50%)

Merging #191 into master will decrease coverage by 0.17%

@@             master       #191   diff @@
==========================================
  Files            39         39
  Lines          1024       1030     +6
  Methods        1005       1007     +2
  Messages          0          0
  Branches         19         23     +4
==========================================
+ Hits            998       1002     +4
- Misses           26         28     +2
  Partials          0          0

Powered by Codecov. Last update 13e2501...0e7b659

I'm ok with the overall changes.
I'm concerned about making the access log config mandatory.
Ideally, the configuration manager (whatever name you want to call it) should look for configs - if it finds them (like commandline params) it will take action on them, otherwise continue with defaults where possible.


API to retrieve a dimensions from a given Terminal instance

VS Live Share extension needs to know current dimensions of a terminal and also to get notified when they're getting changed.
Consider adding a new API to get read-only access to a terminal renderer associated with given terminal instance.

Would exposing this would also solve the issue?
export interface TerminalRenderer {
		dimensions: TerminalDimensions | undefined;

		readonly onDidChangeDimensions: Event<TerminalDimensions>;
}

@Tyriar Yes. That'd solve it. In addition to that we need a method to get a renderer instance:
    vscode.window.onDidOpenTerminal(async terminal => {
        // HOW to get a renderer instance out of the terminal?
        const render = terminal.renderer;
        renderer.onDidChangeDimensions(d => { … });
        await this.terminalProvider.shareTerminal(terminal, this.trace);
    });

Opps, copy and paste mistake above, I mean adding those properties on Terminal, not TerminalRenderer:
export interface Terminal {
		dimensions: TerminalDimensions | undefined;

		readonly onDidChangeDimensions: Event<TerminalDimensions>;
}

Sure. That'd be sufficient to meet our needs!

This API is still in proposed.

I didn't actually want this verified, it will be looked at with https://github.com/Microsoft/vscode/issues/58660

Related: https://github.com/microsoft/vscode/issues/79246

AFAIK this API isn't being used yet as #79246 is needed.
https://github.com/microsoft/vscode/blob/94c6893cad0fd68032905b0a622822951c96c873/src/vs/vscode.proposed.d.ts#L808-L840
cc @IlyaBiryukov


I can imagine that code returning an empty array ([]) for users, because Javascript is an asynchronous language - your logger.debug(users); line is likely going to be executed before your users[i] = rows[0].user_steamid; line.  As far as I can see users should not be undefined.
Regardless, this is not a node-dota2 issue. This issues section is not the place to go for help writing and debugging your applications, unless your issue directly relates to node-dota2 usage.

Yes, it isnt node-dota issue, but i cant understand how to write users and after use this arg in code?


Html and JS code in comments must be escaped

If some comments contains html code, it is interpreted directly
by the browser. And if it contains a script element with JS code,
the JS code is executed!
It mustn't be done.

This is a critical issue. It may freeze the browser with comments like this one ;-)

Thanks a lot!


Rework/template modules

Tests are missing.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@63675e1). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 821000c differs from pull request most recent head f4ef573. Consider uploading reports for the commit f4ef573 to get more accurate results

@@           Coverage Diff           @@
##             main      #47   +/-   ##
=======================================
  Coverage        ?   96.63%
=======================================
  Files           ?       33
  Lines           ?      386
  Branches        ?       34
=======================================
  Hits            ?      373
  Misses          ?       12
  Partials        ?        1

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 63675e1...f4ef573. Read the comment docs.


Unable to send HNT from android wallet.  Unable to calculate fees.

Describe the bug
Entering a HNT address, pressing "Send Max" results in:
"Send Max Error: Unable to calculate fees to send max balance"

Sending a fixed amount results in a failure:
"Failed Transaction"
Unable to complete transaction to 13F..... because the fee was incorrect.  Please try again.

Smartphone (please complete the following information):

Device: Android
OS: 13
App Version 4.1.2

Additional context
Add any other context about the problem here.

Hi,
The API is likely a few blocks behind (we had a long outage + chain halt last night so everything is catching back up) and couldn't fetch the oracle price that determines transaction fees. Please try again in a few hours, apologies for the inconvenience.


Fix homepage crash when member has no permissions

I want to merge this change because this fixes bug causing app to crash when logged user has no permissions.
PR intended to be tested with API branch:
Screenshots

Pull Request Checklist

[ ] All visible strings are translated with proper context.
[ ] All data-formatting is locale-aware (dates, numbers, and so on).
[ ] Translated strings are extracted.
[ ] Number of API calls is optimized.
[ ] The changes are tested.
[ ] Data-test are added for new elements.
[ ] Type definitions are up to date.
[x] Changes are mentioned in the changelog.
[ ] The changes are tested in different browsers (Chrome, Firefox, Safari).
[ ] The changes are tested in light and dark mode.

Test environment config

API_URI=https://master.staging.saleor.cloud/graphql/

This will be fixed in https://github.com/mirumee/saleor-dashboard/pull/1000


Adjusts Sauce Connect settings

Adjusts Sauce Connect settings per https://docs.saucelabs.com/reference/platforms-configurator/
Changes

Slightly adjust case of Sauce Connect settings.

Testing

No change when testing on sauce labs.

Review

@kurtw

:+1: Are there any other configurations?

Is this all that was causing our timeouts or is there more outside of this PR? Either way :+1:

This likely has no effect on the tests, but it looks like Sauce updated these values, so best to align with what they're using.


Fix "TODO: Handle exception null" toast bug in home page

Description
In homepage, if the google play services is not installed in a device, the app is presenting to that user a toast bug which doesnt wanishes by itself on the home screen, as shown in the screnshot. I'd handle this bug and would replace it with a single time appearing info message to the end user, along with the proper steps to be taken for google play services sign in in vritant.
Screenshots

Additional information
No response

hey @jaivsh I am a android flutter developer. I want to work on this.

Hi @jaivsh,
Google Sign-in is already there in the application.
However, I've disabled it temporarily for some time and if you want to fix the null exception issue, you can comment out that code.


[v3.0] Bring back prefixed commands

Pycord now has a bridge_command that let's you create both slash and prefixed commands simulatenously.
Change a few commands from only slash commands to bridge command
Change custom implementation of bot to inherit from discord.ext.bridge.bot. discord.ext.bridge.bot also inherits from commands.bot so there will be no major changes in the code.

push back to [v3.0] because of scale

pushed back indefinitely because bridge commands are definitely not as completed as normal slash commands

need to double check this information on latest releases of pycord


README

Start template: https://github.com/othneildrew/Best-README-Template/blob/master/BLANK_README.md

Should mention that the project was an assessment for data structures and algorithms college course.


Change file naming in generator(0.7.3)

Sorry, I don't know if one pull request can handle changes in two branches, so creating another one PR for 0.7.3(which is actual for me).

Thanks!!


feat: add request headers configuration for the WebSocket client

This feature allows additional headers to be sent during the handshake process from the client.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.20%. Comparing base (c7e6ca0) to head (8a584f2).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main       #5      +/-   ##
==========================================
+ Coverage   88.15%   88.20%   +0.05%
==========================================
  Files           2        2
  Lines         211      212       +1
==========================================
+ Hits          186      187       +1
  Misses         19       19
  Partials        6        6

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Adding deprecation notification to the readme

Please squash all the commits before merging.

Please squash all the commits before merging.

it contains only one commit no need of squash, I have reset to the original commit, added changes and  did the push


Attachment doesn't show up on iPhone Mail app

I don't know where to post this exactly because I can't pinpoint if this is a problem with iOS or with this gem. Sorry about that.
The problem here is that if I use an xlsx template as mail attachment, I can perfectly see it on a browser or another app. However, if I use the default Mail app of iOS, I can tell that it detects that there's an attachment because of the paperclip icon. If I open the email though, it doesn't show the attachment. Any ideas? It would be a great help. Thanks a lot!
P.S. I'm using Rails 4.2 and I have tried both 0.3 and 0.2.1 versions of axlsx_rails.

If you forward the email from the phone can you open it elsewhere?
Or perhaps you can save it to Dropbox and try opening it on the desktop?
If you save the attachment on the desktop, then attach it to a new email, can the phone open it?
Can the phone open any other xlsx file?
If you use axlsx in a script to create a file, does it do the same thing?
Any of those answers will help determine if it is axlsx, axlsx_rails, or the email template process. Let me know what you find.
Noel
Sent from my iPhone

On Mar 10, 2015, at 9:55 PM, Jeriel Paul A. Abayon<EMAIL_ADDRESS>wrote:
I don't know where to post this exactly because I can't pinpoint if this is a problem with iOS or with this gem. Sorry about that.
The problem here is that if I use an xlsx template as mail attachment, I can perfectly see it on a browser or another app. However, if I use the default Mail app of iOS, I can tell that it detects that there's an attachment because of the paperclip icon. If I open the email though, it doesn't show the attachment. Any ideas? It would be a great help. Thanks a lot!
—
Reply to this email directly or view it on GitHub.

If the email is forwarded from the Mail app, the attachment still doesn't appear in Mail app.
However, if it's forwarded from the browser, the attachment now appears in Mail app. It can now also be opened.
I'm not sure about the other questions. Does any of these help? Thanks

Can you post your email / attachment code?
I'm curious if the phone app still has the correct file even when it can't open it. So if you can forward it from your phone to another email and open it on your desktop, it says the basic structure is there, but there i something the phone doesn't like.
Are you able to open other spreadsheets on your phone? I believe you will have to have Numbers or the like to view it.

Here's the code. I tried forwarding the email from my phone to another email but the attachment doesn't appear in desktop.
The attachment only appears in my phone if I forward it from desktop then open it my phone. Hope you can help. Thanks!!
app/mailers/admin/report_mailer.rb
class Admin::ReportMailer < ApplicationMailer
  def sample
    attachments['sample.xlsx'] = {
      :mime_type => Mime::XLSX,
      :content => render_to_string(
        :formats => [:xlsx],
        :template => 'admin/reports/sample'
      )
    }

    mail :to =><EMAIL_ADDRESS>:subject => "sample #{Time.now}"
  end
end

app/views/admin/reports/sample.xlsx.axlsx
wb = xlsx_package.workbook

wb.add_worksheet(name: "Content") do |sheet|
  sheet.add_row ['Content']
end

app/views/mailers/report_mailer/sample.html.haml
%h3 sample #{Time.now}

@jhephs I've never been able to get back to this. Any luck or did you have to abandon it?

@jhephs I've not been able to reproduce this bug. Each attachment I create can be opened in the iPhone mail app. I will close this for now.
It is possibly related to a layout bug that is fixed in 0.5.0. It is also possibly fixed by calling self.instance_variable_set(:@_lookup_context, nil) after you set the attachment. If you try either of these and they are successful please let me know.


Angular 2 Final Release compatibility

Hi,
I saw this was updated 18 days ago. Is it compatible with the Angular 2 Final Release?
Thank you

yes it is, as u can see in the package.json

thank you


Setup AMS, the version variable is defined as 'AMORO_VERSION', but setup use 'AMORO-VERSION'

Rplace version value with the latest Amoro version if needed
export AMORO_VERSION=0.6.0
Download the binary package of AMS
wget https://github.com/NetEase/amoro/releases/download/v${AMORO_VERSION}/amoro-${AMORO_VERSION}-bin.zip
Unzip the pakage
unzip amoro-${AMORO-VERSION}-bin.zip
Start AMS by script
cd amoro-${AMORO-VERSION} && ./bin/ams.sh start

Completed by #29


Mentions

iOS 15 added mentions of other users to Notes. They behave like embedded objects. Need to support them.

Fixed in 6eb27387d4471b924cbcc71e1f4e047279ff81c5


[runtime] Binary section data loading for extra ELF images

Use static constructors for registering dlopen-ed images with the runtime.

For ELF targets, add ImageInspectionInit.cpp that wil be prepended
to each ELF shared object to automatically add the section data
as the object is dynamically loaded (rdar://problem/19045112)

@jckarter couple of notes:
I had another go at adding a struct SectionInfo into the swift_section.S but this time I added it as a new symbol and didnt change the existing ones. This meant I could get rid of the getSectionInfo(). If this isnt ideal I have another version keeping the old method
I couldnt work out what would happen if a 2nd thread dlopend an image while dl_iterate_phdr() was in progress so I just removed all of the dlopen()/dl_iterate_phdr() and just used the constructors. This should have the advantage of eliminating lots of callbacks for images we arent interested in and also saves on dlsym() lookups

:-( We're trying very hard to avoid static constructors. I don't think this is worth the tradeoff if a particular program never asks for conformances.

Static constructors are the only public interface Linux and Windows' dynamic loader have for load-time hooks, so I think it's fine in this case, though we should be careful not to do any more work than absolutely necessary to register the new image with the runtime.

(At the ntdll level, Windows does have LdrRegisterDllNotification, but that's not documented or guaranteed to be supported in future versions.)

Another approach that would maximize laziness and avoid the need for a static constructor, at the cost of making failed lookups a bit more expensive, would be to have the lookup caches fall back to re-iterating all loaded images using dl_iterate_phdr if a lookup doesn't get a cache hit after processing all currently-registered sections. I'm not sure how expensive the dl_iterate_phdr iteration is. The approach could be paired with a simplified static constructor that just sets a loadedNewImages flag in the runtime, which failed conformance lookup would check before re-iterating the images.

@jckarter I updated to remove the SectionInfo that was added to the swift_sections.S
I also renamed some of the functions used by the static init construtor, they may have implied that the caches were being initialised at startup but the lazy initialisation is still being used. The static init construtor just saves the SectionInfo to a list and its not used until initializeProtocolConformanceLookup() or initializeTypeMetadataRecordLookup() is called as is currently the case.
This also has the advantage that we dont need to avoid linking the static construtor into libswiftCore.so
I had a look at glibc but I couldnt see any export of information about images loaded by dlopen. Also, calling dl_iterate_phdr is quite expensive as a lock is held for its entire duration to stop any other images being loaded and dlsym is also quite complex, so I think this current solution does the least work while also being sufficiently lazy.

This would still hardcode an exact set of operations into every dynamic library, which would prevent libswiftCore.so from being upgraded to a version that needs additional per-image hooks. I really think that the static constructor should be either a single call to a function provided by the runtime, so that the runtime has full control of what happens. Organization-wise, that implementation should be able to live entirely in ImageInspectionELF.cpp so that we don't need to export its details out of the runtime, beyond a single public entry point.

Ive simplified the static constructor to just pass an address in the DSO to addNewDSOImage in ImageInspectionELF.cpp. When the caches are later initialised this address can be used to find the image filename using dladdr and the section data loaded via dlopen/dlsym. This keeps all logic in ImageInspectionELF.cpp

@jckarter Can you take another look at this? Thanks!

@jckarter Ive had another look at this and used your suggestion for the constructor of just testing a 'lookup initialized' flag for each cache. This keeps addNewDSOImage() as lazy and minimal as possible.
I also fixed a bug with the dl_iterate_phdr() callback where it gets called for both the dynamic loader and the main executable with a filename of NULL so was loading the data in the executable twice.

@jckarter I have fixed all the minor requests and rebased.
I removed the RTLD_NOLOAD as I dont think it is necessary. dlopen(3) says it is only used to test if a shared object is already resident which should always be the case by the time the dl_iterate_phdr() calls the callback.

@spevans What's the behavior if a different file is on disk at the same path from what was loaded if RTLD_NOLOAD isn't passed? Seems like a nice consistency check.

@jckarter If the file is already loaded then then the filesystem isnt examined. Since the filename comes from either dl_iterate_phdr() or dladdr() then it should already be loaded and in the link map.
However I see your point about it acting as an extra check, the returned handle should never be NULL in which case I think exiting with fatalError() may be the correct action, something like:
void *handle = dlopen(imageName, RTLD_LAZY | RTLD_NOLOAD);
if (!handle) {
  fatalError(/* flags = */ 0, "dlopen() failed on `%s': %s", imageName,
             dlerror());
} else {
  void *symbol = dlsym(handle, sectionName);

does this look ok?

Sounds good. You could leave out the else since the nesting isn't necessary after the if errors out.

@jckarter Ive added  the RTLD_NOLOAD and extra error checking

@swift-ci Please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5c993b45dbab426b7bbccabef0a64bbfacfd9c30
Test requested by - @jckarter

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 5c993b45dbab426b7bbccabef0a64bbfacfd9c30
Test requested by - @jckarter

@swift-ci Please test

Looks great!

Are the CI failures just temporary issues? The log seemed to show it being an issue in lldb?

@spevans There's a known bug in the Jenkins Github plugin that it doesn't like rebases. You just need to trigger CI twice for it to get the right SHA, AIUI. (@shahmishal might have more background)

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 7d2a9aa761e5b35d3f0491469b74d5f6a808d5a7
Test requested by - @jckarter

I see the lldb failure now.  @egranata Are we disturbing the format of any metadata objects LLDB is looking at?

Seems to be correlated, since the builds right before the ones I started for this PR passed…

OK, I'll take a look and see if I can replicate the test failure

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 7d2a9aa761e5b35d3f0491469b74d5f6a808d5a7
Test requested by - @jckarter

@jckarter Looks like the same test failed in the last CI of 'Project OSS - Swift Package - Ubuntu 16.10 (master)' https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_10/328/

OK, might be unrelated then. Let me try again.

@swift-ci Please test

@jckarter I think there is something broken in master for the linux tests as  https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_10 has been failing for the last day or so

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 7d2a9aa761e5b35d3f0491469b74d5f6a808d5a7
Test requested by - @jckarter

I agree. We can't merge additional PRs until master is clean, though. We'll have to wait for the lldb test to be fixed.

Master seems to be clean now, let's try again.

@swift-ci Please test Linux

Thanks again @spevans!


Support  Common Event Format (CEF) format

Motivation
To make it easier to integrate falco and microsoft sentinel I would like to be able to output
falco as CEF formatted messages. This make is also possible to connect/integrate falco with
more security related products wich already support CEF.

centrify
arcsight
splunk

Feature
CEF output looks like syslog but is formated differently. Microsoft Sentinel supports
protocol - tcp
port - 514 or localhost 25226
Format - CEF
TLS  - configurable
more information about CEF:
https://learn.microsoft.com/en-us/azure/sentinel/cef-name-mapping
Additional context
there are multiple go libraries that can help with this:

https://github.com/pcktdmp/cef
https://github.com/xoebus/ceflog

Hello,
This is interesting, if I understand correctly this doc and you, it's just replicate the syslog output but format the payload into the CEF format. I prefer to create a dedicated output for each solution, to have better metrics, even if the way to do in backend is same. Thank you, I'll dig deeper asap.

This looks nice 👍,  yes I think you can add key Values, and some examples from the Microsoft page will tell you if they can automatically recognized

@Issif can you give me an indication when 2.27.0 will be released?

No worries, thanks for the update!
Op ma 9 jan. 2023 11:31 schreef Thomas Labarussias @.***

:

I wanted to release it 3 weeks ago but a PR was blocking, then I was in
holidays and I detected an issue in the CI I'm trying to fix. I hope this
week will be the good one. Sorry for the delay.
—
Reply to this email directly, view it on GitHub
https://github.com/falcosecurity/falcosidekick/issues/382#issuecomment-1375403719,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANXTVAFIIKDNFL5KCLVC4DWRPSJRANCNFSM6AAAAAAR3PFZHM
.
You are receiving this because you authored the thread.Message ID:
@.***>

@aboe76 The 2.27.0 is out, and the helm charts are updated https://falco.org/blog/falcosidekick-2-27-0-ui-2-1-0/

Thank you for the notice.
Op di 10 jan. 2023 16:54 schreef Thomas Labarussias <
@.***>:

@aboe76 https://github.com/aboe76 The 2.27.0 is out, and the helm
charts are updated https://falco.org/blog/falcosidekick-2-27-0-ui-2-1-0/
—
Reply to this email directly, view it on GitHub
https://github.com/falcosecurity/falcosidekick/issues/382#issuecomment-1377479903,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANXTVACKQUTEE2E2LAYLADWRWA2NANCNFSM6AAAAAAR3PFZHM
.
You are receiving this because you were mentioned.Message ID:
@.***>


merge very slow compared to delete + append on larger dataset

Environment
Delta-rs version: 0.13
Binding: python
Environment:

OS: windows

Bug
What happened:
I have a dataset of shape (3066766, 18) and a part of it needs to be updated by a dataset of shape (185004, 18)
The natural way of performing the operation would be using merge().when_matched_update_all() which is super slow ( terminated after waiting for 20mins)
An alternative way I tested is to first dt.delete() then write_deltalake(mode='append'), which is very fast ( < 1s).
What you expected to happen:
Expect the performance of merge().xx() to be faster than delete then append
How to reproduce it:
import pandas as pd
import pyarrow as pa
from deltalake import DeltaTable
from deltalake.writer import write_deltalake
import tempfile

temppath = tempfile.TemporaryDirectory().name
# NYC taxi data sample
df = pd.read_parquet('https://d37ci6vzurychx.cloudfront.net/trip-data/yellow_tripdata_2023-01.parquet')
# make column names lower case due to bug in uppercase #1797
df.columns = map(str.lower, df.columns)
# timezone timestamp issue #1777
df = df.drop(columns=['tpep_pickup_datetime', 'tpep_dropoff_datetime'])

# write to dt
df_temp = df.assign(calculationdate='2023-09-05')
write_deltalake(temppath, df_temp, mode='append', partition_by=["calculationdate"])

# load delta table
dt = DeltaTable(temppath)

# source table to be updated
df_update = df_temp[df_temp.pulocationid.isin([161,  43])]

# method 1 - super slow
dt.merge(
    source=pa.Table.from_pandas(df_update),
    predicate="t.calculationdate = '2023-09-05' and t.calculationdate = s.calculationdate  and s.pulocationid = t.pulocationid",
    source_alias="s",
    target_alias="t",
).when_matched_update_all().execute()

# method 2 - alternative - fast
dt.delete(predicate = "calculationdate = '2023-09-05' and pulocationid in (161,43)")
write_deltalake(temppath, df_update.reset_index(drop=True), mode='append')

#1797  #1777

This may be due to the fact a physical plan is built versus constructing a logical plan. @Blajda has a PR for this feature open.

Yeah further enhancements will need to be done after the conversion to logical plans. Currently the operation rewrites the entire table but this can be optimized when upserts are performed.
Also if the number of records being updated is small then I imagine the cost of the join will become a major factor.

How would this ideally work in practice?
Currently, I process data from some window of time (previous hour, previous day, etc) and save it into a staging dataset.
Then I read the unique partitions which were just changed in the previous step into Polars, sort, and drop duplicates. Then I overwrite the partitions (normally daily or monthly) into my final dataset. The result is that I have the latest version of each unique row based on a unique constraint.
Using merge, I would instead just use when_matched_update_all and insert. Does this trigger the entire table to be overwritten? Some of my tables are hundreds of millions of rows and the data I am upserting would only exist in a single or few partitions.

Using merge, I would instead just use when_matched_update_all and insert. Does this trigger the entire table to be overwritten? Some of my tables are hundreds of millions of rows and the data I am upserting would only exist in a single or few partitions.

Yes the current implementation does this and it is document on the rust side. We should add a warning for python users that current state it should not be used with large tables.
Ideally in the future merge will be able to perform partition pruning and additional pruning based on source statistics to ensure only that on files with modified/deleted records are removed.
Once those enhancements are implemented there should be no issue with using merge for your workflow.

Does #1720 solve this issue?

No it doesn't. Additional work is still required to support efficient upserts.


Lazy Loading Delegate now causes duplicate property error

Something has changed.  I have been able to inject the ILazyLoader.Load method as a delegate (as described above) for the past year or so and it has worked beautifully.  Now, all of a sudden, this causes "The service property 'LazyLoader' of type 'Action<object, string>' cannot be added to the entity type 'MyPoco' because there is another property of the same type. Ignore one of the properties using the NotMappedAttribute or 'EntityTypeBuilder.Ignore' in 'OnModelCreating'."  Is .NET Core now injecting the delegate w/o letting me know?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bbd36f35-e257-d0ed-8f28-f539ddcb71ec
Version Independent ID: 093903d5-f7c7-5a78-c0e5-0e2662dcedef
Content: Loading Related Data - EF Core
Content Source: entity-framework/core/querying/related-data.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @rowanmiller
Microsoft Alias: divega

@kramffud I wasn't able to repro this issue with the code on that page using EF Core 3.0
Please create a small runnable project that shows the exception.

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.
BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.


Update LayoutEventsTest.js

Summary

Changelog

Test Plan

Could you please explain what is the context, why is it needed, and how is it tested?