Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sort() signal 11 on version 73 #529

Closed
codezion opened this issue Nov 4, 2014 · 28 comments
Closed

Sort() signal 11 on version 73 #529

codezion opened this issue Nov 4, 2014 · 28 comments
Assignees
Labels

Comments

@codezion
Copy link

codezion commented Nov 4, 2014

Exactly like 72 with enough queries (Fixed now). Could it be similar buffer size problem at sort() side?

@kneth
Copy link
Contributor

kneth commented Nov 5, 2014

Thanks for the feedback. I'll investigate and get back to you.

@kneth kneth added the bug label Nov 5, 2014
@kneth
Copy link
Contributor

kneth commented Nov 5, 2014

@codezion can you provide some context to the issue? I have tried to increase the number of objects in the unit tests with a factor of 10, and I don't get a signal 11 crash.

@codezion
Copy link
Author

codezion commented Nov 5, 2014

There is already quite much db operation in the app and several tables and a lot of data.
All works perfectly and very fast without any problems until I add any kind of sorting.

With sorting the lib crach after some tens or hundreds db operations and
it seems that it is the amount of operations like it was with 72.

So no timing related. UI is filled with information from the DB.
I can crach the app from its UI so that it crach after 3 touching of UI no matter how I do it.
For example the same operation 3 times, but 3rd kills it and first 2 never.
Each operation is completed like under 1 second and all runs in UI thread.
Much takes place after every touch tho.

When sorting commented out, I can not crach the app no matter how hard i try.

If that information do not help. I can try to create test code for you.
I want to get this working. This lib is so fast and helpful.

Thank you for the fast reacting. Does this info help you?

Here the table I try to sort. There are about 10 longs and Strings more.
(tried to sort with Strings as well)

public class ActorStatus extends RealmObject
{
private long rowId;
...
}

Here the code that do or not do the sorting:

// crash if any way of sorting is in use:
//return realm.allObjects(ActorStatus.class);//.sort("rowId");
return realm.where(ActorStatus.class).findAll();//.sort("rowId", RealmResults.SORT_ORDER_DECENDING);

And here the signal 11 and stack:

D/CrashAnrDetector( 2391): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000010
D/CrashAnrDetector( 2391): r0 00000010 r1 00000000 r2 00000006 r3 617a3318
D/CrashAnrDetector( 2391): r4 00000000 r5 5a976a40 r6 00000000 r7 00000000
D/CrashAnrDetector( 2391): r8 617a3318 r9 617a2dcc sl 41a576a8 fp bedfd3ec
D/CrashAnrDetector( 2391): ip 616ccc5d sp bedfd340 lr 3f800000 pc 6177171a cpsr 00000030
D/CrashAnrDetector( 2391): d0 0000050044a01000 d1 4481e00044a01000
D/CrashAnrDetector( 2391): d2 000004054480a000 d3 0000000000000000
D/CrashAnrDetector( 2391): d4 4056c00000000000 d5 4280000000000000
D/CrashAnrDetector( 2391): d6 000003b900000000 d7 c1200000446e4000
D/CrashAnrDetector( 2391): d8 3f8000003f800000 d9 4434000044040000
D/CrashAnrDetector( 2391): d10 0000000044184000 d11 0000000000000000
D/CrashAnrDetector( 2391): d12 0000000000000000 d13 0000000000000000
D/CrashAnrDetector( 2391): d14 0000000000000000 d15 0000000000000000
D/CrashAnrDetector( 2391): d16 000094c0896d47fa d17 ffffffffffb3b4c0
D/CrashAnrDetector( 2391): d18 0000000000000000 d19 3f80c9714fbcda3b
D/CrashAnrDetector( 2391): d20 3fdf79b47582192e d21 4027043260000000
D/CrashAnrDetector( 2391): d22 4027043260000000 d23 4034000000000000
D/CrashAnrDetector( 2391): d24 3fe269c1e6666666 d25 0000000000000000
D/CrashAnrDetector( 2391): d26 3ff0000000000000 d27 0000000000000000
D/CrashAnrDetector( 2391): d28 3ff0000000000000 d29 0000000000000000
D/CrashAnrDetector( 2391): d30 0000000000000000 d31 0000000000000000
D/CrashAnrDetector( 2391): scr 80000093
D/CrashAnrDetector( 2391):
D/CrashAnrDetector( 2391): #00 pc 000d971a /data/app-lib/com.test.mobile-2/libtightdb-jni.so (_dynamic_cast+33)
D/CrashAnrDetector( 2391): #1 pc 0007fbed /data/app-lib/com.test.mobile-2/libtightdb-jni.so (tightdb::TableViewBase::outside_version() const+20)
D/CrashAnrDetector( 2391):
D/CrashAnrDetector( 2391): stack:
D/CrashAnrDetector( 2391): bedfd300 57c7e838
D/CrashAnrDetector( 2391): bedfd304 401bcaa1 /system/lib/libbinder.so (android::Parcel::freeDataNoInit()+38)
D/CrashAnrDetector( 2391): bedfd308 bedfd330 [stack]
D/CrashAnrDetector( 2391): bedfd30c bedfd360 [stack]
D/CrashAnrDetector( 2391): bedfd310 57c7e838
D/CrashAnrDetector( 2391): bedfd314 bedfd330 [stack]
D/CrashAnrDetector( 2391): bedfd318 40050588
D/CrashAnrDetector( 2391): bedfd31c 401bcb0f /system/lib/libbinder.so (android::Parcel::~Parcel()+8)
D/CrashAnrDetector( 2391): bedfd320 401b64b7 /system/lib/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel
, unsigned int))
D/CrashAnrDetector( 2391): bedfd324 4073c243 /system/lib/libgui.so
D/CrashAnrDetector( 2391): bedfd328 00000001
D/CrashAnrDetector( 2391): bedfd32c 00000001
D/CrashAnrDetector( 2391): bedfd330 00000000
D/CrashAnrDetector( 2391): bedfd334 5b170578
D/CrashAnrDetector( 2391): bedfd338 df0027ad
D/CrashAnrDetector( 2391): bedfd33c 00000000
D/CrashAnrDetector( 2391): #00 bedfd340 00000050
D/CrashAnrDetector( 2391): bedfd344 00000000
D/CrashAnrDetector( 2391): bedfd348 00000000
D/CrashAnrDetector( 2391): bedfd34c 00000000
D/CrashAnrDetector( 2391): bedfd350 00000000
D/CrashAnrDetector( 2391): bedfd354 00000000
D/CrashAnrDetector( 2391): bedfd358 00000000
D/CrashAnrDetector( 2391): bedfd35c 4025eccd /system/lib/libandroid_runtime.so (android::NativeInputEventReceiver::consumeEvents(JNIEnv, bool, long long)+456)
D/CrashAnrDetector( 2391): bedfd360 00000000
D/CrashAnrDetector( 2391): bedfd364 00000000
D/CrashAnrDetector( 2391): bedfd368 00000000
D/CrashAnrDetector( 2391): bedfd36c 59be40b0
D/CrashAnrDetector( 2391): bedfd370 4003e9b8
D/CrashAnrDetector( 2391): bedfd374 00000000
D/CrashAnrDetector( 2391): bedfd378 00000000
D/CrashAnrDetector( 2391): bedfd37c 00000000
D/CrashAnrDetector( 2391): ........ ........
D/CrashAnrDetector( 2391): #1 bedfd388 59be40b0
D/CrashAnrDetector( 2391): bedfd38c 61717c2b /data/app-lib/com.test.mobile-2/libtightdb-jni.so (tightdb::TableViewBase::is_in_sync() const+14)
D/CrashAnrDetector( 2391): bedfd390 61717c1d /data/app-lib/com.test.mobile-2/libtightdb-jni.so (tightdb::TableViewBase::is_in_sync() const)
D/CrashAnrDetector( 2391): bedfd394 59be40b0
D/CrashAnrDetector( 2391): bedfd398 00000009
D/CrashAnrDetector( 2391): bedfd39c 00000000
D/CrashAnrDetector( 2391): bedfd3a0 41a57180
D/CrashAnrDetector( 2391): bedfd3a4 61717d8d /data/app-lib/com.test.mobile-2/libtightdb-jni.so (tightdb::TableViewBase::sync_if_needed() const+10)
D/CrashAnrDetector( 2391): bedfd3a8 59be40b0
D/CrashAnrDetector( 2391): bedfd3ac 616ccc73 /data/app-lib/com.test.mobile-2/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeGetSourceRowIndex+22)
D/CrashAnrDetector( 2391): bedfd3b0 41a57180
D/CrashAnrDetector( 2391): bedfd3b4 de90001d
D/CrashAnrDetector( 2391): bedfd3b8 58439fb0 /dev/ashmem/dalvik-LinearAlloc (deleted)
D/CrashAnrDetector( 2391): bedfd3bc 41a57698
D/CrashAnrDetector( 2391):
D/CrashAnrDetector( 2391): processName:com.test.mobile
D/CrashAnrDetector( 2391): broadcastEvent : com.test.mobile SYSTEM_TOMBSTONE

@kneth
Copy link
Contributor

kneth commented Nov 5, 2014

Thanks for the information. I haven't been able to reproduce it in our unit tests (they actually sort three times).

From the stack trace above, the crash seems to come from get() method in RealmResults (Java_io_realm_internal_TableView_nativeGetSourceRowIndex in the stack trace) and not sort. How do you use the returned RealmResults after sorting?

@codezion
Copy link
Author

codezion commented Nov 5, 2014

Yes. I think sort actually goes through well (I will test more) but if sort is used, some later use of the handle causes the crach. I haven't found a way to clean create a new handle after the sort query. It is like that after sorting some internal pointer becomes empty or someting and when sort is not used, all remains in order. I do not yet understand well how all works internally but seems that data remains at the lib side instead of java side to the last moment, that is good.

@kneth
Copy link
Contributor

kneth commented Nov 5, 2014

The queries in Realm do not copy any data. The RealmResults is a set of pointers (on the C++ layer) to the objects in your realm. Memory is much slower than the CPU, so allocating memory and copying objects make apps slow today - sorry for the marketing speech :-)

You have to be careful not to copy a RealmResults between threads but as I understand you, you're operating in a single thread.

Currently, the sorting is not done in-place i.e., a new RealmResults is created. Maybe we should consider an in-place sort method which might be more efficient in your case.

@codezion
Copy link
Author

codezion commented Nov 5, 2014

The code basically do one query with sort. Then ExpandableListView' adapter starts to draw lines to the UI list based on data in RealmResults.

There are getSize() and getView(position) in the adapter. At the time of getSize() query is done and kept in memory during multiple getViews. Touch of the screen causes redraw. With sort that crach after few touch and without sort never.

Also if I use only realm's size() during the adaper getSize() and do a fresh query during each getView it do not crash. There should not be any changes to the db or anyting during the operation, but I continue commentig out more code to see waht is the core. Not much left anymore tho.

Realm is so amazing fast that fresh queries are not problem, but nobody believes that before trying themself. It is like 0.5 ms wasting of user time. So this way I get ahead with sort() way

@kneth
Copy link
Contributor

kneth commented Nov 5, 2014

@codezion
Copy link
Author

codezion commented Nov 5, 2014

Yes. Thank you for good examples. I need a hierachical list so I think I need to use BaseExpandableListAdapter instead.

@tseglevskiy
Copy link

I have very similar behaviour.

If I pass realm.where(YPRegion.class).findAll().sort("region") to RealmBaseAdapter, it will crash.
If I pass realm.where(YPRegion.class).findAll(); it works.

@codezion
Copy link
Author

There was mention in another post that maybe this crash happens because of two instances of Realm (in same process). I am quite sure there was only one all the time. I haven't anymore the exact code left, but could try to recreate it at some point. My current fix is still the fresh queries inside each method so any Realm data is not reused between methods. Huge amount of queries, but works with sort this way.

@tseglevskiy
Copy link

I've manually create only one instance, but later create two independent Adapters with two requests.

Will the source or the log help you?

@kneth
Copy link
Contributor

kneth commented Nov 12, 2014

@tseglevskiy If you can share your code (either publicly or privately), it would be of great help.

@tseglevskiy
Copy link

The project is here:
https://github.com/LizaAlert-HotLine/AndroidMobileWorkplace

The right tab contains data from Realm tables. Corresponding code is here:
https://github.com/LizaAlert-HotLine/AndroidMobileWorkplace/tree/master/AndroidMobileWorkplace/src/main/java/ru/lizaalert/hotline/yp

If in the file
https://github.com/LizaAlert-HotLine/AndroidMobileWorkplace/blob/master/AndroidMobileWorkplace/src/main/java/ru/lizaalert/hotline/yp/ui/YellowPagesFragment.java
change the line 122 from
regions = realm.where(YPRegion.class).findAll();
to ...realm.where(YPRegion.class).findAll().sort("region");
the crash will happens.

@benjaminprakash88
Copy link
Contributor

@tseglevskiy the sort works in unit tests not sure why it crashes with your app. For now can you try and make another RealmResult that does the sorting.
resultList = realm.where(YPRegion.class).findAll();
regions = resultList.sort("region");

We are looking into the problem. Hope it helps for now.

@tseglevskiy
Copy link

@benjaminprakash88 did you try to use my app? Did you take the crash successfully?

Your peace of code looks like the mine except you use variable for ResultList. Unfortunately it crashes by the same way.

@benjaminprakash88
Copy link
Contributor

@tseglevskiy Yeah i did try it and it did crash with the
regions = realm.where(YPRegion.class).findAll().sort("region");

Once i changed it like that i could run the app. Where do the app crash for you?

@kneth
Copy link
Contributor

kneth commented Nov 13, 2014

I have tried to single step through the app, and it seems that the crash happens in line 213 in YellowPagesFragment.java (spinner.setSelection(position);). I really don't understand what has to do with the sort() call easier :-(

The async task called in line 166 does have its own Realm instance. This is fine as sharing realm instances and objects across threads has undefined behaviour.

@tseglevskiy
Copy link

@kneth nope, the crash happens independently of spinner.setSelection(). right now it happens in 2 seconds after this call (I've printed two messages to log around it).

I made a copy of RealmBaseAdapter and put log messages at start and finish of every method. Crash happens in the method getItem in call realmResults.get(i), i=0. Interesting that it is the second call of this method. The first one with the same i = 0 runs correctly.

@tseglevskiy
Copy link

It think, it may help you. Look into your io.realm.internal.TableView.nativeToString. My assumption is you have problems with sorting non-english UTF-8 strings.

W/dalvikvm(24994): JNI WARNING: input is not valid Modified UTF-8: illegal continuation byte 0x2e
W/dalvikvm(24994): string: ' region name phone description
W/dalvikvm(24994): 0: 0 МОСКВА 112 +74959379911 Если нам зв...
W/dalvikvm(24994): 1: 0 БРНС (Бюро ?... +74956882252 Здесь очен?...
W/dalvikvm(24994): 2: 0 Справочная... +74994450102 +749944...
W/dalvikvm(24994): 3: 0 "Жди меня" +74956601052 Сюда предл?...
W/dalvikvm(24994): 4: 0 "Доктор Лиз... +74959539486 +749574... Пн-Чт: c 11 до...
W/dalvikvm(24994): 5: 0 Милосердие... +79857644911 Курсируют ?...
W/dalvikvm(24994): 6: 0 Православн... +74959729702 http://www.miloserdi...
W/dalvikvm(24994): 7: 0 Социальный... +74993570180 Подскажут, ...
W/dalvikvm(24994): 8: 0 Телефон до?... +74956949229
W/dalvikvm(24994): 9: 0 Городской ?... +74959379911
W/dalvikvm(24994): 10: 0 Социальный... +74957
W/dalvikvm(24994): in Lio/realm/internal/TableView;.nativeToString:(JJ)Ljava/lang/String; (NewStringUTF)
I/dalvikvm(24994): "main" prio=5 tid=1 NATIVE
I/dalvikvm(24994): | group="main" sCount=0 dsCount=0 obj=0x416c1578 self=0x416131c0
I/dalvikvm(24994): | sysTid=24994 nice=0 sched=0/0 cgrp=apps handle=1074028540
I/dalvikvm(24994): | state=R schedstat=( 0 0 0 ) utm=110 stm=20 core=1
I/dalvikvm(24994): #00 pc 000012fe /system/lib/libcorkscrew.so (unwind_backtrace_thread+29)
I/dalvikvm(24994): #1 pc 0005fff6 /system/lib/libdvm.so (dvmDumpNativeStack(DebugOutputTarget const_, int)+33)
I/dalvikvm(24994): #2 pc 00054080 /system/lib/libdvm.so (dvmDumpThreadEx(DebugOutputTarget const_, Thread_, bool)+395)
I/dalvikvm(24994): #3 pc 000540ee /system/lib/libdvm.so (dvmDumpThread(Thread_, bool)+25)
I/dalvikvm(24994): #4 pc 000386a8 /system/lib/libdvm.so
I/dalvikvm(24994): #5 pc 00039a74 /system/lib/libdvm.so
I/dalvikvm(24994): #6 pc 0003be46 /system/lib/libdvm.so
I/dalvikvm(24994): #7 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #8 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #9 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #10 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #11 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #12 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #13 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #14 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #15 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #16 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #17 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #18 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #19 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #20 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #21 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #22 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #23 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #24 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #25 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #26 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #27 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #28 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #29 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #30 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): #31 pc 000349a4 /data/app-lib/ru.lizaalert.hotline-1/libtightdb-jni.so (Java_io_realm_internal_TableView_nativeToString+71)
I/dalvikvm(24994): at io.realm.internal.TableView.nativeToString(Native Method)
I/dalvikvm(24994): at io.realm.internal.TableView.toString(TableView.java:871)
I/dalvikvm(24994): at io.realm.RealmResults.getTable(RealmResults.java:-1)
I/dalvikvm(24994): at io.realm.RealmResults.get(RealmResults.java:95)
I/dalvikvm(24994): at io.realm.YetAnotherAdapter.getItem(YetAnotherAdapter.java:65)

@codezion
Copy link
Author

This point do not make difference to this bug hunting, but because of the adapters are on table, the adapter example needs a face lift.

The idea of holder pattern is to get rid of extra findViewById() calls, now it calls it all the time, so the holder in the example is useless. By using holder pattern correctly, the speed of Realm becomes better visible. Changes of timing affects to visibility of bugs sometimes as well.

Two changes.
Change inner holder class to static class (yes there will still be unique instances of it for each view).
And move findViewById to where holder is created.
So:

private static class MyViewHolder {TextView tvTimeStamp;}

@OverRide
public View getView(int position, View convertView, ViewGroup parent)
{
MyViewHolder mViewHolder;
if(convertView == null)
{
convertView = inflater.inflate(android.R.layout.simple_list_item_1, null);
mViewHolder = new MyViewHolder();
mViewHolder.tvTimeStamp = (TextView) v.findViewById(android.R.id.text1);
convertView.setTag(mViewHolder);
}
else
{
mViewHolder = (MyViewHolder) convertView.getTag();
}
mViewHolder.tvTimeStamp.setText(realmResults.get(position).getTimeStamp());
return convertView;
}

@tseglevskiy
Copy link

@codezion Thank you very much, I've done it. Really it was my question yesterday why we heed the holder. :)

@kneth
Copy link
Contributor

kneth commented Nov 14, 2014

@tseglevskiy The string handling in Java is a bit strange if I remember correctly. And you have a lot of non-latin characters, and we might have an issue there (I notice the nativeToString in your log above).

@kneth
Copy link
Contributor

kneth commented Nov 14, 2014

@tseglevskiy I have reviewed our code at the JNI layer (C++ code), and I have found some old - and potential wrong - string conversions. I'm grateful for your patience and your log file above!

@kneth
Copy link
Contributor

kneth commented Nov 21, 2014

@tseglevskiy We haven't been able to resolve the issue. Just to rule out a problem with UTF strings, can you try to use a spreadsheet with only English letters?

@bmunkholm
Copy link
Contributor

We now got a theory now for the sort issue, but just need to make and test a possible solution. We hope to be able to provide a fix for this very early next week.

@bmunkholm
Copy link
Contributor

This should be fixed now with release 0.75.1. Please reopen if that's not the case!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants