xsnrg post=70059 wrote: That might be advisable. I reverted to a copy of the build I had from March 19, and it worked great for the rest of the night last night.

running `git diff c882e29822f6b692a6d6db2e48e99cab88ac31a5 .` it looks like the previous version of the Camera SDK was 1.16.3. The EAF and EFW were updated on the 19th.
I think we can leave those alone and only change the camera version. Thoughts?

Yes, 1.16.3 is also what I run for observations (a compile from March 11).
ISTR that there were also reports of issues with the filter wheels here in the forum.  They do work for me, though, as does the EAF.


knro post=70056 wrote:  does ./asi_camera_test causes a crash as well?

Just tried it with my laptop and the ASI183MC.  Did crash, too:
Please input the <width height bin format> with one space, ie. 640 480 2 0. Leave w/h to zero to use maximum.
0 0 1 2

set image format 5496 3672 1 2 success, Will capture now a 100ms image.
Image successfully captured. Writing image to image.raw file...
asi_camera_test: ./os/threads_posix.h:46: usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) == 0' failed.
Aborted (core dumped)
The created image.raw does have the correct size of 5496·3672·2=40362624 byte.



seescho post=70012 wrote: So, reduzing the picture size a bit let the crash dissapeare


I can confirm that, same here.  Reducing the FOV of my ASI183 to 3672x3672 prevents it from crashing!  But already at 4000 it starts crashing again, so no workable solution.

FWIW, I also tried using a USB2 cable to connect.  But no difference to USB3.


pawel-soja post=69992 wrote: In original library (1.17), there are probably larger double buffers used for communication with the camera.
The usbfs_memory_mb value should be at least '6 x Resolution'. For now, these are guesses, I need to analyze the library more.
Anyway, to rule out a memory problem, I suggest temporarily increasing the usbfs_memory_mb value and testing indi with different ZWO libraries.


256MB should be enough for the ASI183MC, no?  Nevertheless, I tried with both 512 and 1024, no change there.  Crashes with both.  It does take a while though:  The image is downloaded and displayed, and only some 3s later I get the crash message which states
Child process 14326 died
2021-04-13T13:52:57: Driver indi_asi_ccd: stderr EOF


Hi Jo,

In my experience it is enough to keep the current nightly/devel of indi, and only downgrade the version of libasi. Haven't yet tested my filter wheel, though - will do later today.


Just for confirmation:
With latest, you refer to 1.17, yes? So that one fixes the original issue in this thread, but causes crashes for some?


Addendum: I had not checked the syslog so far. It actually says

Apr 12 11:27:52 woodstock.pitnet kernel: usb 2-1: Process 28984 (indi_asi_ccd) called USBDEVFS_CLEAR_HALT for active endpoint 0x81
Apr 12 11:27:53 woodstock.pitnet kernel: indi_asi_ccd[28976]: segfault at 35 ip 00007fb5551d4646 sp 00007fb53e442b90 error 4 in libusb-1.0.so.0.3.0[7fb5551ca000+e000]

(I also noticed that the new udev rules no longer contain the chmod to 0666 for ASI devives; but it also crashes when run as root....)



xsnrg post=69941 wrote:

jpaana post=69937 wrote: Libasi package also contains the udev rule file, which has that usbfs 256MB memory line in the old version, but not in new one.

This is true, but it still exists. It was just moved to INDIlib, and should have the same effect. This change has been working for me now for  some time. Jasem moved it there because many devices require it, so indilib is a good central place to manage it.
I still suspect changes in the SDK/driver from ZWO as having some differences to figure out.

Ah, it's in 99-indi_auxiliary.rules now.  Was wondering, too.  But I had checked that the setting was at 256, so that was/is not the issue.
But if things work with the previous SDK and not with the latest, it's either a bug in the SDK, or some change in the API (or responses) the is not reflected by the INDI code.  The SDK changelog however is not very helpful, just referring to 'bug fixes' :(


Addition:  If I downgrade only libasi, in my case to 1.9.0-21_gd9a5e309 from March 11, everything runs fine.  That is the old SDK,  So it obviously is an issue of the ZWO SDK?


So this is the EQMOD driver yes?
This is only for building the unit test. For normal operation, gmock is not needed. I have neither gmock nor gtest installed, and it builds fine.
If I read the CMakeLists.txt right, that one isn't correct. It tries to find both GTest and GMock, but if GTest is found it wants to build the tests, even if GMock wasn't found.
For a quick solution you could edit CMakeLists.txt, line 146, and set INDI_BUILD_UNITTESTS to FALSE...

(in my case the packages would be called gmock and gtest, but that won't help you, as it's openSUSE....)


pawel-soja post=69903 wrote: This can actually be a problem for a specific camera.


I can at least confirm that, while the ASI183MC is crashing the driver every time, the 290MMmini works without issues...


No idea. I started kstars from the terminal, and got messages about the xml device file,

Dispatch command error(-1): Device ZWO CCD ASI183MC Pro not found
<setTextVector device="ZWO CCD ASI183MC Pro" name="DRIVER_INFO" state="Idle" timeout="60" timestamp="2021-04-11T09:39:07">
<oneText name="DRIVER_NAME">
<oneText name="DRIVER_EXEC">
<oneText name="DRIVER_VERSION">
<oneText name="DRIVER_INTERFACE">

I deleted the xml files, then it started without the error, but it still crashed. I was running in local mode. So I tried running indiserver manually and connect to remote localhost. Also crash, and the indiserver says
2021-04-11T09:45:29: Driver indi_asi_ccd: stderr EOF
Child process 17789 died

Also tried deleting ~/>ZWO/ASIconfig.xml, without change.

I tried running it in gdb, not sure if that is successful (I started indiserver manually, then connected via 'gdb -p PID').
Here's the output:
Thread 4 "indi_asi_ccd" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff55ad640 (LWP 18722)]
0x00007ffff6ef9a9a in __futex_abstimed_wait_common64 (
    futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
    private=private@entry=0, cancel=cancel@entry=true)
    at ../sysdeps/nptl/futex-internal.c:74
Downloading source file /usr/src/debug/glibc-2.33-4.1.x86_64/nptl/../sysdeps/nptl/futex-internal.c...
74          err = INTERNAL_SYSCALL_CANCEL (futex_time64, futex_word, op, expected,
(gdb) bt
#0  0x00007ffff6ef9a9a in __futex_abstimed_wait_common64 (
    futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
    private=private@entry=0, cancel=cancel@entry=true)
    at ../sysdeps/nptl/futex-internal.c:74
#1  0x00007ffff6ef9aff in __GI___futex_abstimed_wait_cancelable64 (
    futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
    private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123
#2  0x00007ffff6ef3260 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
    mutex=0x5555555a2860, cond=0x5555555ade70) at pthread_cond_wait.c:504
#3  __pthread_cond_wait (cond=0x5555555ade70, mutex=0x5555555a2860)
    at pthread_cond_wait.c:619
#4  0x00007ffff6da50e0 in __gthread_cond_wait (__mutex=<optimized out>, 
    at /usr/src/debug/gcc11-11.0.0+git183291-1.4.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux/bits/gthr-default.h:865
#5  std::__condvar::wait (__m=..., this=0x5555555ade70)
    at /usr/src/debug/gcc11-11.0.0+git183291-1.4.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/std_mutex.h:155
#6  std::condition_variable::wait (this=this@entry=0x5555555ade70, __lock=...)
    at ../../../../../libstdc++-v3/src/c++11/condition_variable.cc:41
#7  0x00007ffff7e4dfa7 in std::_V2::condition_variable_any::wait<std::unique_lock<std::recursive_mutex> > (this=this@entry=0x5555555ade70, __lock=...)
    at /usr/include/c++/10/condition_variable:321
#8  0x00007ffff7e4d768 in std::_V2::condition_variable_any::wait<std::unique_lock<std::recursive_mutex>, INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()>::<lambda()> > (__p=..., __lock=..., this=0x5555555ade70)
    at /usr/include/c++/10/condition_variable:330
#9  operator() (__closure=0x555555597b28)
    at /home/pit/Sources/indi/libs/indibase/thread/indisinglethreadpool.cpp:31
#10 std::__invoke_impl<void, INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#11 std::__invoke<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > (__fn=...) at /usr/include/c++/10/bits/invoke.h:95
#12 std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > >::_M_invoke<0> (this=0x555555597b28)
    at /usr/include/c++/10/thread:264
#13 std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > >::operator() (this=0x555555597b28)
    at /usr/include/c++/10/thread:271
#14 std::thread::_State_impl<std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > > >::_M_run(void) (
    this=0x555555597b20) at /usr/include/c++/10/thread:215
#15 0x00007ffff6daade4 in std::execute_native_thread_routine (
    __p=0x555555597b20) at ../../../../../libstdc++-v3/src/c++11/thread.cc:82
#16 0x00007ffff6eed299 in start_thread (arg=0x7ffff55ad640)
    at pthread_create.c:473
#17 0x00007ffff6a9a3b3 in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Does that help in any way?


Is there any news on this?  I just tried to connect my camera (ASI183MC) locally to the laptop, and trying to take an image crashes the indi driver.  Streaming works on the first try (I can even select sub-fields etc), but a restart (also from within the stream window to change exposure) will crash it....
This is with libindi-1.9.0-92_gbd9110b4.  No issues with the previous one I had installed (libindi-1.9.0-21_gd9a5e309 as of March 11)