<azonenberg>
Soooo for ngscopeclient i'm overhauling the "export" functionality
<azonenberg>
it's no longer going to be accessed via the file menu
<azonenberg>
it's now going to be via filters
<azonenberg>
Each export filter will have a parameter for output file name
<azonenberg>
and a mode for selecting one of four possible operating modes: continuous append and continuous overwrite (every time the filter graph executes, the input waveforms are written to the file, optionally overwriting previous contents)
<azonenberg>
and manual append and manual overwrite (waveform data is written over / appended to the file when you click a button in the filter properties dialog)
<azonenberg>
So for example you could have a .pcap exporter in continuous append mode fed by a stream of Ethernet frames
<azonenberg>
Does that sound reasonable?
<azonenberg>
(ping lain, @louis, @MP, miek, monochroma, Bird|otherbox, balrog if you have comments?)
<d1b2>
<azonenberg> (ping @MP again since irc bridge didn't tag you right)
<d1b2>
<louis> (If we wanted, we could keep the File->Export menu and have it just create a filter and open it's properties)
<d1b2>
<louis> A related handy ability would be to run scopehal headlessly to execute the full filter-graph once and exit. This is something I find myself doing sometimes to e.g. process an on-disk WFM into I2C and export that.
<azonenberg>
That would be useful, file a ticket
<azonenberg>
Also planned, but no current ticket AFAIK, is to have a menu option to export the current filter graph as C++
<azonenberg>
i.e. you get a bunch of C++ code that instantiates the filter graph in a headless form so you can call it in an ATE platform or something
<azonenberg>
and/or have a data driven architecture where you can load a scopesession's filter graph and not get all of the gui along with it
<azonenberg>
that may happen as part of the scopesession-v2 work lain is hopefully starting any day now (poke poke)
<_whitenotifier-9>
[scopehal-apps] azonenberg ec748a6 - Added new context menu for export filter category
<_whitenotifier-9>
[scopehal-apps] azonenberg 9b0c874 - Session: explicitly free export filters when session is closed
<d1b2>
<edgetriggered> Interesting- I built a newer commit of ngscopeclient and now it just always segfaults. No getVkHeaderVersion assertion failed messages any more.
<azonenberg>
lol
<azonenberg>
edgetriggered: can you get me a stack trace?
<d1b2>
<edgetriggered> Will it make it through the IRC bridge? I posted a couple of address sanitizer reports earlier.
<d1b2>
<edgetriggered> And is there a way to get more info out of ASan? I built debug target but see output like: #1 0x7fcbbee28a7a in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) (/home/chris/src/antikernel/scopehal-apps.git/build/lib/scopehal/libscopehal.so+0x628a7a)
<d1b2>
<edgetriggered> Shouldn't it have a better idea of what source file and function?
<azonenberg>
in gdb? run 'bt' to get a backtrace
<d1b2>
<edgetriggered> No, I mean address sanitizer and/or leak sanitizer.
<d1b2>
<edgetriggered> I'll rebuild without it. I couldn't seem to produce a backtrace in gdb if the sanitizer is included.
<d1b2>
<edgetriggered> Thread 1 "ngscopeclient" received signal SIGSEGV, Segmentation fault. 0x00007ffff40aee0e in __GI___libc_free (mem=0x2f000) at malloc.c:3344 3344 if (chunk_is_mmapped (p)) /* release mmapped memory. */ (gdb) bt #0 0x00007ffff40aee0e in __GI___libc_free (mem=0x2f000) at malloc.c:3344 #1 0x00007fffef805c39 in vk_free () at ../mesa-22.3.6/src/vulkan/util/vk_alloc.h:79 #2 vk_common_SetDebugUtilsObjectNameEXT
<d1b2>
() at ../mesa-22.3.6/src/vulkan/runtime/vk_debug_utils.c:167 #3 0x00007ffff64ff6d0 in terminator_SetDebugUtilsObjectNameEXT (device=0x555556110c50, pNameInfo=0x7fffffffb9c0) at /usr/src/debug/vulkan-icd-loader/Vulkan-Loader-1.3.240/loader/generated/vk_loader_extensions.c:4560 #4 0x0000555555c1c5a0 in vk::raii::Device::setDebugUtilsObjectNameEXT(vk::DebugUtilsObjectNameInfoEXT const&) const (nameInfo=<optimized out>,
<azonenberg>
you're in vkSetDebugUtilsObjectNameEXT in Mesa
<azonenberg>
and assigning a name to a surface
<azonenberg>
this is a mesa bug i think... was it tnt who stumbled across it? sec
<azonenberg>
edgetriggered: anyway, the workaround is to comment out the setDebugUtilsObjectNameEXT call
<azonenberg>
this is only important for debugging vulkan API issues, and worst case means you see a handle instead of a nice object name in debug messages
<azonenberg>
long term, if someone wants to add a PR to disable that specific line if the vulkan implementation is Mesa, that will probably be helpful
<azonenberg>
oh nvm it was tavycats who had the issue
<azonenberg>
"@azonenberg they all work, except for surfaces which don't work b/c wsi_CreateXcbSurfaceKHR creates an VkIcdSurfaceXcb which doesn't participate in mesa's vk_object system, and the way Khronos's Vulkan Loader works, I'm not sure its even possible to properly fix it, except for mesa to just error gracefully in vkSetDebugUtilsObjectNameEXT"
<azonenberg>
I just poked tavy to see if they had any updates on a proper fix
<azonenberg>
but yeah, you should be able to use ngscopeclient for the near term if you comment out VulkanWindow.cpp:203-207
<d1b2>
<edgetriggered> Thanks, it's unusual that it sometimes works when I run it through gdb.
<azonenberg>
you're probably getting memory corruption in mesa and sometimes being lucky with what's impacted :p
<azonenberg>
@edgetriggered can you pastebin me a "vulkaninfo" dump?