Segmentation fault when creating instance of a third-party class that has the name of a godot class but that is not in a namespace.

Godot version
v4.1.1.stable.custom_build [bd6af8e0e]
System information
Godot v4.1.1.stable (bd6af8e0e) - Linux Mint 21.2 (Victoria) - Vulkan (Forward+) - integrated Intel(R) Graphics (RPL-P) () - 13th Gen Intel(R) Core(TM) i7-1360P (16 Threads)
Issue description
I'm working on a gdextension. It builds on other libraries that I have made a long time ago. One of those other libraries contains a class called Object. It is not declared in a namespace.
If in my C++ gdextension I declare a static ::Object * object {new ::Object {}}; then the godot editor, when opening a project that uses my gdextension, crashes immediately, typically with malloc(): unaligned tcache chunk. Also exporting the project from the command line fails.
Also other no-namespace classes with a name of a class in the godot namespace, like ::Node, ::Node3D, and ::CSGPolygon3D, cause segmentation faults. The class ::Vector3 is okay, however.
This issue was discusses at 36627-object-class-in-library.
Steps to reproduce
Start with for example the gdextension example from the godot docs. Add a header file Object.h like
class Object {   static Object * const object; };
and a source file Object.cpp like
::Object * const ::Object::object {new ::Object {}};
Build the gdextension, open the project in the editor, the editor should crash.
Minimal reproduction project
I hope that the description of the steps to reproduce suffice.

Thanks for the report!
I may be seeing similar behavior in one of my extensions.
I created a ScriptInstanceExtension class inside my GDExtension to provide an API similar to Godot's ScriptInstanceExtension because that class isn't exposed - instead you need to work through the GDExtensionScriptInstanceInfo2 struct, and this let me give it a nicer API. Anyway, I was getting a segfault when memdelete()ing an instance of this class, and when I walked through the code in the debugger, it appeared that it was calling ~ScriptInstanceExtension() for the unexposed engine class, rather than the class in my extension.
If I put my ScriptInstanceExtension in a namespace, then this stopped happening, and everything worked as expected.
This is really, really strange behavior. It's as if the dynamic linker is deciding to link the ScriptInstanceExtension class to the one in the engine?
I'm also on Linux (Ubuntu 22.04). I think the default behavior on Linux is to export all symbol, and I wonder if it's treating the Godot binary like an .so that's exporting all classes? I haven't had a chance to try this, but I wonder if we compiled Godot with -fvisibility=hidden it would help?

I did a little bit more research, and we could also try passing RTLD_DEEPBIND to dlopen() when loading the GDExtension. The man page says:

Place  the  lookup  scope  of the symbols in this shared object ahead of the global scope.  This means that a self-contained object will use its own symbols in preference to global symbols with the same name contained in objects that have already been loaded.

That last idea seems to fix it in my testing! (I didn't try the first idea, since that seemed like more work. ;-))
I created PR https://github.com/godotengine/godot/pull/82973 with the change
@ariesssss Can you try building Godot with that PR, and see if that fixes the problem for you?

Thanks for your work. I'm not exactly sure where you want me to make the change to the call to dlopen(), can you give me a hint? Or alternatively, could you add a header file with
class Node
{
  public:

    explicit Node ();

    static Node * const x;
};

and a source with
#include "X.h"

Node::Node ()
{
}

Node * const Node::x {new Node {}};

When I then export the project, it hangs, it does not even output the first line:
Godot Engine v4.1.1.stable.custom_build.bd6af8e0e - https://godotengine.org

You are definitely on to something, because if I remove the constructor, then the export works fine. But I'm not convinced that this will fix my issue, because in my case the symbols are different. With nm -C I see symbols like
0000000000461fd0 T Node::Node()

for my Node and
00000000004bfe40 T godot::Node::_ready()

for ::godot::Node. I don't think RTLD_DEEPBIND can have an effect on these, can it?

@ariesssss:

I'm not exactly sure where you want me to make the change to the call to dlopen(), can you give me a hint?

It's the change to the Godot engine from this PR #https://github.com/godotengine/godot/pull/82973 - you can apply the patch from there and recompile Godot, or you can download the build artifacts from CI (I just added some instructions to the PR description explaining how to do that).

for ::godot::Node. I don't think RTLD_DEEPBIND can have an effect on these, can it?

I'm hopeful that it'll fix the issue (it fixes a similar issue for me), but only testing will say for sure!

However, something very strange is going on. It is as if godot is searching for a constructor of ::godot::Node, and finds a constructor for ::Node. Under normal circumstances I don't see how that can be even remotely possible. Your fix seems to me to be more like a fix of symptoms, and not a fix of the root cause of the issue.
I still think it is better to figure out what exactly goes wrong here. If not, the issue will undoubtedly come back to haunt us somewhere in the future. Just my 2 cents ...

I just realised that in my case compiled code for the ::Node and ::godot::Node classes are actually in the same library. This prompted me to look for the existance of a ::Node class in the godot source code (as opposed to the godot-cpp source code). And indeed there is one, in scene/main/node.h! So now it is clear what happens. The ::godot::Node class in godot-cpp has nothing to do with it, it's the ::Node class in godot that is the issue here. And then it makes perfect sense why RTLD_DEEPBIND fixes the issue.

Awesome, thanks for testing!

The ::godot::Node class in godot-cpp has nothing to do with it, it's the ::Node class in godot that is the issue here. And then it makes perfect sense why RTLD_DEEPBIND fixes the issue.

Yep! It's still weird to me, that the dynamic linker would mess with symbols that are defined - in my mental model of how it works, it only links undefined symbols, but I guess we learned something new. :-)

I'm by no means an expert on dynamic linkers. But the gdextension library, opened by the dlopen call, is used to get the initialization function of the gdextension. The godot editor executable is otherwise not aware of that library. So I have a hard time understanding how symbols in the gdextension library can conflict with symbols loaded by the godot editor executable.

Upon re-reading the explanation for RTLD_DEEPBIND

Place  the lookup scope of the symbols in this shared object ahead of the global scope.  This means that a self-contained object will use its own symbols in preference to global symbols with the same name contained in objects that have already been loaded.

This makes me think that it is actually the other way round (from what I assumed up to now, anyway): not my ::Node class interferes with the code in the godot editor, but the godot editor code interferes with my ::Node class.
I now do think that it is a bit unfortunate that the godot editor code is, by and large, not in a namespace.


Colorscheme not updating for bufferline.nvim

I'm an avid user of nvim-base16 and I recently started to use bufferline.nvim. I also automatically change the colorscheme of my desktop (incl. neovim) on sunrise and sunset. This amounts to reloading a lua file that looks like
vim.opt.background = light
vim.cmd([[colorscheme base16-atelier-forest-light]])

This works great for everything except the bufferline, which does not change to a base16 theme and instead stays the previous theme. I have tested with different themes, and only nvim-base16 exhibits this behaviour (i.e. gruvbox -> base16 fails to work, but base16 -> gruvbox works fine).
See akinsho/bufferline.nvim#490, which this issue supersedes.

I'm not sure I see how this is an issue with nvim-base16, this plugin is just a glorified runner for :highlight ... commands. You should reopen the issue in bufferline, if you can figure out the reload mechanism for colors (instead of just using highlight group) it's using then maybe something can be done.

Hi, I've finally traced this to other colorschemes calling highlight clear, right before setting g:colors_name.
For example, rose-pine does this here: https://github.com/rose-pine/neovim/blob/main/lua/rose-pine.lua#L69
For example, adding the line hi clear to the beginning of colors/colorscheme base16-atelier-forest-light.vim fixes this issue.
Can we re-open?

I'm not entirely clear why I removed that in the first place 🤔 I see it removed last year in my git log but without a clear commit message.


chore(main): bump version to 2.1.7

:robot: I have created a release beep boop
2.1.7 (2023-01-07)
Bug Fixes

prebuild lifecycle not working (89b32df)

Continuous Integration

update sync-dev commands (830b7cd)

Documentation

update attention part of README.md (ca36095)
update README.md (26d0782)

Chores

added barrel files for exception (f41cdb9)
changed http status to nestjs enum (803bc83)
changed node env from 'local' to 'development''' (ca3dc99)
changed to bufferLogs approach in main.ts (682fc9a)
deps: upgrade dependency packages (7f74a33)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/kenso312/nestjs-v9-webpack-boilerplate/releases/tag/v2.1.7 :sunflower:


Temperature check on possible memory leak in Holistic JS solution

Hello! I'm using the Holistic web solution in a WebRTC streaming application.
We've occasionally seen Holistic processing crash in a way that seems indicative of a memory leak:

I'm currently unsure about whether the Holistic processing crash is the cause or a symptom of another issue. I've done some memory profiling, but haven't found a reliable way of reproducing it yet.
Since I don't have too much visibility into the Mediapipe JS internals, I was just hoping to get a temperature check on whether the Mediapipe team thinks:

This issue could be related to the Mediapipe internals / you've seen it before in other contexts
This is definitely not a Mediapipe issue and likely a bug in my application logic

Basically just trying to determine where to invest additional debugging / investigation efforts.
FWIW I also came across this thread https://bugs.chromium.org/p/chromium/issues/detail?id=1174675 which indicates there could be some memory leak issues in Chromium that can affect use cases like WebRTC, but the rate of leakage described there seems too slow compared to what I'm perceiving in my application.
Thanks in advance for your help! Sorry that I'm not able to provide any more details besides that single stack trace. Please let me know if you need any additional information and I'd be happy to circle back with it.

I see this.  Will check it out.

I have gone through our testing on Holistic and I see no memory leaks on the basic solution.  However, I may still be able to help.  WASM requires that any class created must subsequently be deleted to avoid memory leaks.
Can you check to see if it's possible that you are creating multiple copies of Solution without also calling close() on those solutions?  Remember that close() does return a Promise, so you will need to await or .then().

Thanks for the quick reply @mhays-google!
Your comment helped me find out that I was indeed instantiating multiple copies of Holistic in one of my flows. I'm not sure yet if this is also the root cause for the flow that originally led to my question though, but will continue digging and circle back. Just wanted to respond sooner than later to thank you for the useful advice!
Also just for my curiosity: not sure if this is expected since I don't have visibility into the close() implementation, but it didn't actually seem to have that big an impact on reclaiming memory.  I tested both calling close() and just manually nulling the ref. The latter allowed the application to reclaim ~80 MB of memory (which seems to correlate the size of the instantiated Holistic object). The former didn't have a noticeable effect (though it's possible that I just didn't let it run long enough to gain a sizable memory footprint). Could you give me some more insight into what close() is actually doing underneath the hood? (the types / documentation you linked here https://github.com/google/mediapipe/issues/1408#issuecomment-810652766 are a bit vague)

Hello again, @mhays-google
After making the above fix and doing some more profiling, it seems like there's still some seemingly unbounded memory allocation happening.
Here are some memory snapshots from my application:

The culprit is always this JsArrayBufferData object that grows very large (I've seen this grow over 1.1 GB previously). This issue seems to be present in other Mediapipe models as well: https://github.com/google/mediapipe/issues/1956#issuecomment-830473628.
When I check the retainers that are keeping this JsArrayBufferData from getting garbage collected, the createMediapipeSolutionsPackedAssets and createMediapipeSolutionsWasm strings are the most notable to appear (the redacted blocks are just the name of my project just for privacy reasons)

Interestingly, I'm able to observe the same memory issue and retainers for this demo: https://mediapipe.dev/demo/holistic.

Potentially notable similarities between my project and that demo: they both use the CDN method of import and therefore the Holistic object and createMediapipeSolutionsPackedAssets / createMediapipeSolutionsWasm functions are available globally in the Window.
Tangentially(?), I've since also tried the following to address this and neither have helped:

Importing Holistic through the NPM package (https://www.npmjs.com/package/@mediapipe/holistic) so that Holistic isn't present in the Window (my locateFile still points to https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>so the createMediapipe* functions are still in the Window)
Manually setting createMediapipeSolutionsPackedAssets and createMediapipeSolutionsWasm to null in my application to force garbage collection

Even more interestingly, the issue also seems to be present in https://mediapipe.dev/demo/holistic_remote/, albeit to a less extreme degree(?). Noteworthy: the implementation for this demo seems to differ from the previous based on what I can tell from the heap snapshot and the lack of Holistic, createMediapipeSolutionsPackedAssets, and createMediapipeSolutionsWasm in the Window

Do you have any more clues / thoughts as to why this might be happening? Sorry for the block of text, just trying to give you as much information as I can about what I've tried so far :sweat_smile:

A few things:
.close() resolves to an equivalent call to delete ptr in C++.  Since these classes are allocated in C++ on the heap, they still need to be released.  Here, JSArrayBufferData represents your heap.  The fact that it continues to grow points specifically to new pointers being allocated in C++ without subsequently being deleted.
When you set a reference to null (or undefined) in JavaScript, it is able to garbage collect those objects which live exclusively in the JavaScript world.  However, if they are linked to any objects which are effectively proxies into some object living in C++, then you will no longer have the ability to tell C++ to release the resources.  It would be a bit like creating an object that adds a few items to a map, and then deleting that object before it has the opportunity to remove its contributions from said map.
Finally, it may be the case that heap memory grows but does not shrink.  If it does, we are not taking advantage of this (the same happens often in Java applications where they get the opportunity to grow, but never compact their own memory to allow shrinking it again).
Ok, with that out of the way:
createMediapipeSolutionsPackedAssets and createMediapipeSolutionsWasm should only ever be called once for a page.  The fact that they show up multiple times tells me that one of the following things have occurred:

(Most Likely) You are calling send multiple times without waiting for the returned Promise to resolve.  send will initialize the graph, which can potentially load the WASM.
You are manually calling initialize and not waiting for the Promise to resolve.
You are creating more than one Solution.

Can you check if any of these are the case?
Thank you!
Michael

Your comment has been useful to understand more about whats going on @mhays-google. I have a memory leak and have been trying to remove it for the past few days (the same issue with JSArrayBufferData), and I have checked that I am not doing any of the 3 issues you mentioned.

The fact that it continues to grow points specifically to new pointers being allocated in C++ without subsequently being deleted.
Isn't that done in C++, so shouldn't the mediapipe library be deleting these? Im not sure why deleting any variables in JS are going to affect this. .close isn't necessary because this memory leak happens as the program runs, and close is just called when you're done using the whole mediapipe solution. (i.e. call it right at the end)

Finally, it may be the case that heap memory grows but does not shrink. If it does, we are not taking advantage of this

Is this not the definition of a memory leak? Isn't this the problem all along? Could you clarify what you mean. If you the heap keeps growing because more arrays are created over time, I don't see how I can solve this in the javascript side.
PS: I also wish https://github.com/google/mediapipe/issues/1956 was not closed, because the issue was not addressed. @tyrmullen assumed it was one thing and closed it immediately. Though it is very related to this.

Even if the memory being leaked is in C++ code, that doesn't necessarily mean that the MediaPipe library can fix this.  As mentioned by mhays-google, one key problem is that JS has no finalizers, which means it's unfortunately impossible for C++ code to know when garbage is collected.  The workaround for this is usually to force users to call some sort of .close() function as soon as resources are ok to be freed, on any JS object which is backed by C++ memory.
Also, the heap memory growing and never shrinking is not necessarily a memory leak, as long as there's a cap on the growth.  For example, if the C++ code starts out needing 10MB of heap space, but needs 20MB when a hand is visible, the heap size may leap to 20MB and then stay there, even if no hand is visible, so it technically only needs 10MB.  This can be expected behavior rather than a leak, since the next time you need 20MB, no more memory is allocated (and in fact, you usually don't want to be freeing and reallocating large chunks of memory on the fly, for performance reasons).
However, for your specific issue, I'm not actually convinced that the leak is even in the C++ memory...  I agree with your reading that there's only one C++ heap shown there, but 27MB doesn't seem too unreasonable pre-garbage-collection for a C++ heap size; is that particular value increasing steadily over time in your measurements?  Furthermore, when I run the smallest Holistic demo (without CodePen UI) here, and then just look at Task Manager (right clicking on the headers there so I can enable "JavaScript memory", it looks like the "live" JavaScript memory never increases beyond a certain point (which would indicate a leak there).  However, the overall memory does appear to be increasing over time, even on this isolated MediaPipe demo.  So this makes me wonder where that other >100MB in your snapshots (which seems to be growing continuously) is coming from-- perhaps there are some DOM elements which are being kept alive in JS/TS code (or console.print logs) accidentally?  This will definitely require additional investigation.
On an unrelated note, I actually closed the other issue not as solved, but rather to deduplicate, precisely because it sounded like effectively the same problem as here, so it seemed more useful/efficient to have everything live on the same thread moving forwards (to "break the tie" I usually just choose the first issue reported, and close the others).
As for open-sourcing, this is a subject of much ongoing discussion and work.  More information can be found on issues 1408, 1741, and for some lower-level BUILD details 877.

Thanks for your interesting reply 🙃

doesn't necessarily mean that the MediaPipe library can fix this

I don't think we're expected to call .close on every frame, are we? I expected that once new Results for an image/ frame are returned from the library, that the old arrays are released in mediapipe/ automagically. I'm not sure of the distinction between the memory of mediapipe in JS and in C++ though.

Even in my application (and the codepen), chrome's Performance tab's memory measurement is constant, it is the memory tab which shows it growing until 2GB and crashing, taking between 10 minutes to 20 minutes in my app. It seems like you know why this is, is it because the performance tab only shows JS memory, and the memory dump shows more? I don't know 🤷🏻♂ Here is a picture of the Mediapipe codepen's memory growing? It does seem to grow in steps though, it was constant at 927MB for a few minutes, then suddenly 1028MB showed up.

perhaps there are some DOM elements which are being kept alive in JS/TS code

Isn't the other 100MB the same 100MB we're talking about, they are ArrayBuffer's "retained" by createMediapipeSolutionsPackedAssets.
PS: Okay I understand why it was closed, but I replied there and I was afraid everything was going to waste in that issue.

No, you shouldn't need to call .close() on every frame.  I was just explaining why the solution might not always be in C++ even if the apparent leak is in C++ memory; but aside from the Solution itself, I don't recall any of the intermediate results needing .close().  In general, anything which is a native JS data type (or a structure/dict/array of those) will not require a .close() call-- it would only be for something our API returns which keeps its functionality in C++ (so interacting with it would generally be through function calls-- like the Solution).
As for memory layout, the memory in C++ is basically a special siloed-off ArrayBuffer.  JS can peek into this and even manipulate it, but to the C++ code, this is the only memory it knows.  And I suspect you're right about the memory profiling differences-- Performance shows JS memory, while Memory dump shows everything.  In fact, if you check out Task Manager (with "JavaScript memory" as mentioned above), then I'd expect the "memory used" readings would grow and shrink with Memory dump values (but will likely be larger, since this covers stuff even the Memory dumps don't), while the "JavaScript memory" readings would correspond with Performance values.  And FWIW it looks like C++ memory might not count as "JavaScript memory", although I'm not quite sure where the distinction is drawn.
From your screenshot above, I see two different large chunks of memory, one which is ~27.5MB (@49035), and one which is positively massive (almost 1GB! (@419095)).  The expanded trace shows that the wasm Module (@87191) is causing ~27.7MB to be retained, 27.5MB of which I'm assuming would be from that smaller chunk of memory (@49035).  But I believe the wasm Module retains the entire native C++ heap, so it seems the C++ memory isn't growing beyond 27-ish MB.  So the question to ask now is "where is that ~1GB coming from?".
When I repeat your experiment with the various solutions, I only see a memory increase over time for "Holistic" and "FaceMesh", which makes me think this is facemesh-specific (so I'll look into FaceMesh alone next, to cut out some of the extra noise).  Curiously, though, my memory dump details look a little different than yours.  For me, the increase appears to clearly occur in the wasm Module's C++ memory area, indicating a leak there.
TL;DR: I'm not sure why we're getting different readouts, but at least for me, I seem to see a C++ memory leak somehow related to FaceMesh-- we don't do anything special for this module that I can think of, though, so I'm not yet sure what could cause this.

That's interesting, I haven't done a lot of WASM stuff but I'd be interested to help out.

So the question to ask now is "where is that ~1GB coming from?".

I was trying to investigate that, but the codepen is broken, have the library/ model files have been removed?
Failed to load resource: the server responded with a status of 403 () https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>

I'll have the memory leak fix up later today.

Was the fix included in yesterday's release v0.3.1620694839?, sadly I still observe a memory leak in my app. Unfortunately the codepen is still broken, perhaps thats the old codepen and you created a new one?
I'm also curious why there are so many digits in the version string 👀

Hi @afogel, Can you raise an another issue with complete details in it.
@codylieu Thank you for the update we are closing this issue now.

@sgowroji why did you close this? This is an open issue.The fix was not released or confirmed by @mhays-google.

@sgowroji thanks for the fast response -- I added the notes here b/c @ben-xD had mentioned that the version referenced earlier in the thread meant to address the memory leak also seemed to break the holistic js model altogether. Given that it's been about 2 weeks since the release and the current release is broken, I figured I'd add the stack trace information if that might help resolve some of the issues.

@sgowroji Just to clarify: we are still facing this issue. I was just thanking your team for all the work you've put into this

Sorry, accidentally closed the issue. Reopened it. Just to clarify: we are still facing this issue @sgowroji. My comment was just thanking you and your team for all the work you've put into this so far!

@mhays-google @sgowroji Any updates on this?

The fundamental issue here is that the underlying memory management system is quite brittle and makes debugging leaks rather tricky.
If one "delete()" call is forgotten (and many are required for the various nested structures involved-- with no easy way to determine which are potentially missing), then the C++ memory is leaked opaquely, only visible when the leak is large enough or persists long enough.
This is definitely something we'd like to fix (and we have several ideas for doing so), but for most Solution APIs this isn't as bad a problem, since the data being brought from C++ back to JS is so very small (I don't think this issue is face_mesh- or holistic-specific; instead I believe that the face mesh data just happens to be the only data large enough to produce a noticeable memory leak within a reasonable amount of time).
That said, because face mesh data is so large, this results in MB/s being leaked, which is quite serious.  So while a memory management system restructuring will likely not occur for a while yet, I will attempt to track down and submit a patch in the next day or two to at least solve this particularly problematic case of face mesh data leakage when transferring from C++ to JS.

I've submitted a patch-- the next JS Solutions update to "face_mesh" and "holistic" should no longer have this issue.  Please confirm or let me know if that's not the case when the next release occurs.

@tyrmullen Thank you so much for the update, Hi @afogel & @codylieu, Please test the above in the next release and reach us if you still face the similar issue. Thank you!

@sgowroji I just checked the npm repository, but haven't seen another release yet (The latest release I see is v. 0.3.1620694839, published a month ago)? Do you have a sense of when it will be released? Thanks!

@sgowroji @tyrmullen Same question as @afogel. Still not seeing any new releases on: https://www.npmjs.com/package/@mediapipe/holistic. Any idea when a version with @tyrmullen's fix might be released?

It should be there now in version 0.4.1625245411. Sorry for the delay and confusion.

@chuoling @sgowroji I'm not able to check to see whether the fix is working because I'm having the same issue as before on version 0.3.1620694839, though the error appears to occur in the simd_wasm_bin.js file rather than the wasm_bin.js.
I tried it on both Chrome and FireFox and it crashed. Can we reopen until this is resolved?
Thanks!
Uncaught (in promise) RuntimeError: abort(undefined) at jsStackTrace@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.js:9:66465
stackTrace@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.js:9:66717
abort@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.js:9:39700
_abort@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.js:9:178721
@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.wasm:wasm-function[7398]:0x50a52e
@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.wasm:wasm-function[7390]:0x50a243
@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.wasm:wasm-function[7401]:0x50a5a3
@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.wasm:wasm-function[253]:0x1eabb
@https://cdn.jsdelivr.net/npm/@mediapipe/holistic@0.4.1625245411/holistic_solution_simd_wasm_bin.wasm:wasm-function[191]:0x1657d
SolutionWasm$send@https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>line 9 > Function:9:8
d/<@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94005:401
W@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93971:39
la/this.next@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93972:89
h@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:318
promise callback*f@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:457
h@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:315
promise callback*f@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:457
Z/<@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:468
Z@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:261
parcelRequire<["../node_modules/@mediapipe/holistic/holistic.js"]</</A.send@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94002:29
b/<@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94017:399
W@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93971:39
la/this.next@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93972:89
Z/<@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:491
Z@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:93981:261
parcelRequire<["../node_modules/@mediapipe/holistic/holistic.js"]</</A.send@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94017:330
onFrame@file:///Users/repo/thv.js/dist/js/main.js:49:30
r@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94081:858
q/<@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94081:660
FrameRequestCallback*q@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94081:626
t/a.video.onloadedmetadata@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94081:754
EventHandlerNonNull*t@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94081:702
parcelRequire<["../node_modules/@mediapipe/camera_utils/camera_utils.js"]</</p.prototype.start/<@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94082:297
promise callback*parcelRequire<["../node_modules/@mediapipe/camera_utils/camera_utils.js"]</</p.prototype.start@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:94082:279
@file:///Users/repo/thv.js/dist/js/main.js:55:9
EventListener.handleEvent*$_ready@file:///Users/repo/thv.js/dist/engine/core/monogatari.js:18314:10
@file:///Users/repo/thv.js/dist/js/main.js:31:9

@afogel I think we should open a separate issue for the error you're running into, since it seems unrelated to the memory leak, and we have other ways to verify the leak-fix (so it should not be blocking validation).  For example, the facemesh demo mediapipe.dev/demo/face_mesh should no longer have this severe memory leak.

done! #2267

I know this issue is closed, but I am struggling with memory leaks as described above.
I am using the face mesh demo  run on local server (no code pen). I changed nothing about the code.
My versions are as follows:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
Chrome Version 95.0.4638.69 (Official Build) (arm64)

I observed significant increases of JS heap size over time. I sampled every minute for 10 minutes and observed these increases.

31.4,50.3,76.1,88.7,104,121,143,168,168,199
I also observed this increase monitoring heap size over the course of 40 seconds.

Any suggestions on how to resolve this?

@tyrmullen the memory leak originally described by @codylieu and now by @crecord seems to exist again as well in<EMAIL_ADDRESS>cc: @mhays-google

I compare some different approaches here. It seems that using this demo with NPM + the dev dependencies is the most promising for memory. Maybe a similar environment could help for using the facemesh mediapipe example.

Hmm... I've run code.mediapipe.dev/codepen/face_mesh in full screen mode
and in the editor.  I let it go for 10 minutes.  Not only was it not
leaking, but it was also hovering around 10 megabytes.
We definitely had leaks in the past (months ago), but we've addressed
this.  Is it possible that you have a bad version downloaded?
Specifically, in your constructor, are you maybe feeding a bad prefix to
locateFile?

Unfortunately, I can verify that both of those demo scenarios leak on CodePen as well (current facemesh CodePen with no changes, and pose with version bumped to @0.5.1635988162).
Profiling makes it seem that there may even be two distinct leaks: one in C++/Wasm memory (System/JsArrayBufferData, which exhibits sporadic "leaps" in size) like before, and a much smaller one which appears to be in pure JS memory ((array), which slowly continuously grows over time).  I believe the latter is related to rendering code, since if the tab is backgrounded (and thus should not be streaming in video frames), then it stops growing (while the other leak does not).
@mhays-google 10MB sounds very low for the facemesh demo (even when first starting up); maybe double-check to see if your memory profiler was accidentally set to profile the CodePen JVM and not the MP demo (the demo JVM should be the larger of the two)?  Also, you might not see most of the leaks unless you actually take heap snapshots, since the live JS heap report just on the memory profiler tab seems to ignore things like the C++/Wasm memory for some reason.

@tyrmullen and @mhays-google any update on this?
cc: @crecord

@tyrmullen @mhays-google
Can we please get an update on the fix? We are experiencing crash issue on mobile devices due to this leak.
Facemesh version used: 0.4.1633559619

@tyrmullen and @mhays-google any update on this?
thanks!
Vince

I haven't yet had time to try to track this down, but I've at least isolated the regression.  Version 0.4.1625245753 had my initial large C++ leak fix, and no C++ memory appears to be leaked up through version 0.4.1628005669.  However, versions 0.4.1629159166 and now 0.4.1633559619 (most recent version as of this posting) both have a large C++ memory leak again.  For now, unless you need the new features, I'd recommend using one of those older versions as a workaround.

Is there any update? We met the same problem of momory leaking with facemesh in our web application, yet we do need the iris result so we can't work around with 0.4.1628005669. Is it possible to fix the problem?


Use Three-Fatline to enable linewidth in firefow

Hi,
In Xtreme1, Box Linewidth doesn't work on firefox :
Due to limitations of the OpenGL Core Profile with the WebGL renderer on most platforms linewidth will always be 1 regardless of the set value.
Can we use three-fatline (exemple : https://threejs.org/examples/webgl_lines_fat.html) instead to make it work in firefox ?
Best,
Clément

Hi, we currently do not support the function of changing line width, and there are currently no plans to use three-fatline.


Asteroids (enhancement idea)

I might be missing something, but I was wondering if there was any plan toward more granular asteroid mining times. I've adjusted the multiplier which impacts asteroids broad-scope, but the idea to provide asteroids as a source of otherwise difficult-to-obtain material is a tempting avenue. Concept wise, it provides another tech-tree to pursue for some later-game materials such as awakened draconium (some of my players are heavy industry, but couldn't care less about swinging a sword at a Chaos Guardian). In the spirit of balance I would prefer this come at significant (borderline punitive) cost, and time-to-mine is the most obvious price (on top of rarity, ore-to-stone ratios, etc). Anyway, just pitching the idea and the reasoning, but know it's a feature request on a mod already biting off a heck of a lot to chew (and handling it well). Thoughts for placement would be a secondary multiplier on a per-asteroid type basis (value 1 matching the global cfg setting, < || > 1 would adjust accordingly. That or some kind of 'per distance' factor on the 200 scale. Admins could work within that between assigned-to asteroid and the global setting. It's more roundabout, but might be more reasonable to implement in an already constructed system and config structure.....'Other' other idea, if you're feeling evil (or excessively ambitious) would be tagging asteroids to star systems and force them to perform the mining off-overworld and deal with item transport logistics. With tesseracts (or other cross dimensional means) this isn't much of a barrier for the work involved in coding that, but figured I'd add it while spitballing. Thanks for reading!

I'd like to avoid tying a time multiplier directly to distance, perhaps instead it would be better as its own setting in the asteroid.xml file in the asteroid tag.  If it were treated as a decimal it should give very fine control over mining time.  I suppose the real trick would be somehow alerting the player to its mining time.  I guess that would be in the observetory somewhere.
I'm likely not going to get around to requiring launching from another planet or system.  Though I may incorporate something like that later for asteroid belts or fields.

implemented in next build


Call Ux issues

If I call from Computer to Mobile the answer button is hide (pic1)

If I call from mobile to computer and activate mobile camera I get this (pic2)

Thanks !!

Ok thanks for the reply
I've tested and I got no sound..
When receiving the call on computer I can see that the @domain doesn't show it shows "Myusermame@undefined" instead
Yes I've set the permissions
I can only see each device own camera on Mobile I can see the mobile camera and on computer I can see computer camera and not the other device camera it's blank
Thanks !

Sorry, a couple more questions as I try and reproduce:
Are you using the demo STUN/TURN server (bottom of the github readme); if not could you test with that?
If that also doesn't work, could you create two accounts on the demo site 'databag.coredb.org' and try it there?

Sorry, a couple more questions as I try and reproduce:
Are you using the demo STUN/TURN server (bottom of the github readme); if not could you test with that? If that also doesn't work, could you create two accounts on the demo site 'databag.coredb.org' and try it there?

I'm using my stun server, give me some minutes to test

Yes just tested with the test stun server on my server and got the exact same results has described above
If I call computer - mobile the "Myusername@domain" shows correct
If I call mobile - computer get "Myusername@undefined"
Thanks !

I think there are two issues, the '@undefined' is one, but the video should still playback.
To confirm, in that test with the demo stun/turn, the video playback also didn't work?

Correct it shows only the own device camera,
If I allow the 2 cameras the window will become like in (pic2)
If I allow one shows this

I am able to reproduce your issues around '@undefined'. I will fix these and see if they have an impact on the video not playing back. Thank you for your help with this bug!

I am able to reproduce your issues around '@undefined'. I will fix these and see if they have an impact on the video not playing back. Thank you for your help with this bug!

Great ! A lot of functions had been added.
Thanks !

When you get a chance, can you update the software and then try the calling feature again?
I pushed an update to both the container and mobile apps.
Thanks again for your help!

When you get a chance, can you update the software and then try the calling feature again? I pushed an update to both the container and mobile apps. Thanks again for your help!

Alright the name now fits in mobile and the @undefined on webpage shows the name of the person calling, without the @domain
Great ! Thanks !!
But still no luck on transmitting video/audio the (pic2) is still happening, do you have your server working with it ?
I notice this on docker logs when calling
2023/05/23 12:18:43 /internal/api_status.go:108 write tcp <IP_ADDRESS>:7000-><IP_ADDRESS>:34292: write: broken pipe
2023/05/23 12:18:43 GET /status?mode=ring Status 4m0.007138238s

Could you create two test accounts at [https://databag.coredb.org/#/create] and see if the calling works. You will probably need to click the 'filter' icon to find the other account (as shown in screenshot). That is my public demo server, and it works for me.
If that doesn't work, I've been reading that some networks may require tcp for NAT traversal, and you may want to try the webrtc url as: turn:<IP_ADDRESS>:3478?transport=tcp
I'll keep researching the issue, sorry for the trouble.

Tried the tcp instead udp same issue
and have the same issue with using accounts on your server same has when use mine
Assuming the call appears on the other end we can assume the relay server is working ? the test site shows everything correct
I've currently tested with mullvad browser and librewolf
the mobile rom is /e/ foundation OS
If you want to try debug it
Thanks !!

With the call appearing on the other end, we can only assume the call signaling is working, which doesn't require NAT traversal.
I didn't understand what you meant by 'the test site shows everything correct'
On my laptop, I just opened librewolf and logged into my test account sturn1. I then opened a 'new private window' on my same laptop, and logged into my other test account sturn2. I made a call between the two and enabled video. For me it all works as expected. Because this is on the same device, I think WebRTC avoids any NAT traversal. Is this a test you could also do? If it works, I think I could focus on NAT traversal being the issue.
Thanks for your patience!

No problem at all, in the coturn tutorial page theres a test page
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/?ref=gabrieltanner.org
Ill try it tomorrow

With the call appearing on the other end, we can only assume the call signaling is working, which doesn't require NAT traversal.
I didn't understand what you meant by 'the test site shows everything correct'
On my laptop, I just opened librewolf and logged into my test account sturn1. I then opened a 'new private window' on my same laptop, and logged into my other test account sturn2. I made a call between the two and enabled video. For me it all works as expected. Because this is on the same device, I think WebRTC avoids any NAT traversal. Is this a test you could also do? If it works, I think I could focus on NAT traversal being the issue.
Thanks for your patience!

Alright, I tested your method and it works on both servers using the same computer, but there's little utility in that hehe
Thanks !!

hah, yes I agree, but I think it does suggest NAT traversal is the issue.
When you have time, could you do another test? Could you enable 'wireless hotspot' on your phone, and connect your PC/laptop to the phone hotspot. Then try calling from one account on your phone to the other account on your PC/laptop.
If this works, then there is something about webrtc, or the way I have configured it, that doesn't play nice with your home network.

hah, yes I agree, but I think it does suggest NAT traversal is the issue.
When you have time, could you do another test? Could you enable 'wireless hotspot' on your phone, and connect your PC/laptop to the phone hotspot. Then try calling from one account on your phone to the other account on your PC/laptop.
If this works, then there is something about webrtc, or the way I have configured it, that doesn't play nice with your home network.

Ok, so doing this test resulted in the same issue (pic2) no video on the other end
Thanks !

hmmm.....perhaps NAT traversal is not the issue. Perhaps it's related to the foundation os, which I haven't tested on, but I do want to support.
I am going to buy an old Pixel 5, which seems well supported by /e/ foundation os, and hopefully be able to reproduce it there.
It will be a little while before I get back to you, but thanks for your support!

Alright, yes it could be, it's a fork from lineageOS that is developed by /e/ foundation and support currently 227 Smartphones Models
Great ! Take your time it's not a fatal bug and the feature is "new" so it is expected
Just one suggestion add a notification or something for when someone calls you, otherwise you'll only get the call if you are inside the app
Thanks once again

I did add notifications for calls, but you might need to logout, then log back in.
Its not ideal, but the notifications to receive are registered at login time. I might need to change that.

It doesn't appear on this os if I open the app the call box is already there
Give me some time your server send me sound now on the call, the video still isn't working

Yes sound is working now on my server too !!
this is... weird at least
It is fixed call sound works great !!!!
Is the video call still under development ?

Hmm, are you saying I should add notifications to the broswer side?
I don't really follow the last message. Does audio work now, or is this a message intended for a different thread?

The notification call doesn't seem to work on /e/
Someway to see that someone is calling you (If I'm on android menu and receive a call I can't see, if I open the app I can see someone is calling.
Yes, it was working all along it seems it can't function if you're using the tor network for mobile app, If turned off it work, the call not the video

Well that's great news. It makes sense it wouldn't work with tor. Hopefully we'll get video working once my Pixel5 arrives.

Alright we can mark this issue has close, at least we found a bug
Cheers !


Error, function_clause, cow_http2:window_update [0,infinity]

Cowboy is crushing when submitting a large form. Works well with forms containing less information/fields. The crush is happening when cowboy is trying to read the request body (i'm not sure this is the cause of the problem but i noticed it so i wrote it here maybe it gives you a hint on what's going on).
Crush is happening in cowlib, function
window_update(StreamID, Increment) when Increment =< 16#7fffffff
StreamID = 0 and Increment = infinity atom and because this =< guard do not match
== Browser ==
Google Chrome Version 74.0.3729.131 (Official Build) (64-bit) on Fedora
== ERLANG crash_report ==
PLEASE NOTICE: Data was removed from messages and replaced with ...>> because it contains sensitive information from my project posted through the form. However i kept the first bytes from the urlencoded body because they look quite suspect to me including those 0 bytes.
I also shorten cowboy source files paths (the part related to my project) so the crush report will be more easily readable.
[[{initial_call,{cowboy_tls,connection_process,['Argument__1','Argument__2','Argument__3','Argument__4','Argument__5']}},
{pid,<0.2014.0>},
{registered_name,[]},
{error_info,{error,function_clause,[{cow_http2,window_update,[0,infinity],[{file,"/cowlib/src/cow_http2.erl"},{line,461}]},{cowboy_http2,commands,3,[{file,"/cowboy/src/cowboy_http2.erl"},{line,578}]},{cowboy_http2,loop,2,[{file,"/cowboy/src/cowboy_http2.erl"},{line,198}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,249}]}]}},
{ancestors,[<0.277.0>,<0.276.0>,ranch_sup,<0.263.0>]},
{message_queue_len,1},
{messages,[{ssl,{sslsocket,{gen_tcp,#Port<0.62>,tls_connection,<0.280.0>},[<0.2013.0>,<0.2012.0>]},
<<0,11,36,0,0,0,0,0,1,98,108,101,...>>}]},
{links,[<0.277.0>,<0.2015.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,1598},
{stack_size,27},
{reductions,2318}],
[{neighbour,[{pid,<0.2015.0>},
{registered_name,[]},
{initial_call,{cowboy_stream_h,request_process,['Argument__1','Argument__2','Argument__3']}},
{current_function,{cowboy_req,read_body,2}},
{ancestors,[<0.2014.0>,<0.277.0>,<0.276.0>,ranch_sup,<0.263.0>]},
{message_queue_len,0},
{links,[<0.2014.0>]},
{trap_exit,false},
{status,waiting},
{heap_size,610},
{stack_size,52},
{reductions,597},
{current_stacktrace,[{cowboy_req,read_body,2,[{file,"/cowboy/src/cowboy_req.erl"},{line,491}]},{cowboy_req,read_urlencoded_body,2,[{file,"/cowboy/src/cowboy_req.erl"},{line,513}]},{xhttp_lib_request,parse_post,3,[{file,"src/xhttp_lib_request.erl"},{line,64}]},{xadmin_lib_router,init,2,[{file,"src/xadmin_lib_router.erl"},{line,50}]},{cowboy_handler,execute,2,[{file,"/cowboy/src/cowboy_handler.erl"},{line,41}]},{cowboy_stream_h,execute,3,[{file,"/cowboy/src/cowboy_stream_h.erl"},{line,296}]},{cowboy_stream_h,request_process,3,[{file,"/cowboy/src/cowboy_stream_h.erl"},{line,274}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,249}]}]}]}]]=CRASH REPORT==== 5-Jun-2019::09:12:53.272567 ===
crasher:
initial call: cowboy_tls:connection_process/5
pid: <0.2014.0>
registered_name: []
exception error: no function clause matching
cow_http2:window_update(0,infinity) (/cowlib/src/cow_http2.erl, line 461)
in function  cowboy_http2:commands/3 (/cowboy/src/cowboy_http2.erl, line 578)
in call from cowboy_http2:loop/2 (/cowboy/src/cowboy_http2.erl, line 198)
ancestors: [<0.277.0>,<0.276.0>,ranch_sup,<0.263.0>]
message_queue_len: 1
messages: [{ssl,
{sslsocket,
{gen_tcp,#Port<0.62>,tls_connection,<0.280.0>},
[<0.2013.0>,<0.2012.0>]},
<<0,11,36,0,0,0,0,0,1,98,108,101,...>>}]
links: [<0.277.0>,<0.2015.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 1598
stack_size: 27
reductions: 2318
neighbours:
neighbour:
pid: <0.2015.0>
registered_name: []
initial call: cowboy_stream_h:request_process/3
current_function: {cowboy_req,read_body,2}
ancestors: [<0.2014.0>,<0.277.0>,<0.276.0>,ranch_sup,<0.263.0>]
message_queue_len: 0
links: [<0.2014.0>]
trap_exit: false
status: waiting
heap_size: 610
stack_size: 52
reductions: 597
current_stacktrace: [{cowboy_req,read_body,2,
[{file,
"/cowboy/src/cowboy_req.erl"},
{line,491}]},
{cowboy_req,read_urlencoded_body,2,
[{file,
"/cowboy/src/cowboy_req.erl"},
{line,513}]},
{xhttp_lib_request,parse_post,3,
[{file,"src/xhttp_lib_request.erl"},{line,64}]},
{xadmin_lib_router,init,2,
[{file,"src/xadmin_lib_router.erl"},{line,50}]},
{cowboy_handler,execute,2,
[{file,
"/cowboy/src/cowboy_handler.erl"},
{line,41}]},
{cowboy_stream_h,execute,3,
[{file,
"/cowboy/src/cowboy_stream_h.erl"},
{line,296}]},
{cowboy_stream_h,request_process,3,
[{file,
"/cowboy/src/cowboy_stream_h.erl"},
{line,274}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,249}]}]

Are you calling read_body or similar function with a length set to infinity?

Let me check everything in my handler until the crush occurs and come back with the answer.

You where right. Thank you very much!
%% somewhere along my code
ReadLength = infinity,
%% later i call:
cowboy_req:read_urlencoded_body(Req, #{length => ReadLength, period => Timeout})

I can't understand how i came up with this. Is it possible older version of cowboy used infinity? (I reused some code from an old application using old cowboy < 2 version)


Add SourceLink to the build

Blocked by https://github.com/ctaggart/SourceLink/issues/156

No longer blocked. Upgrade to 2.0.2.

Thanks, @ctaggart. Already working to verify on appveyor with f8cfa6f7552.

Well, that one is going to fail, evidently because at least the test projects don't build with portable PDBs by default. I'll work to fix that.

Fixed by a42927509dbf4b7b4f7b870ebab6d1880cdb45b8


CARLA with 2 fps on linux and 60 on windows on the same machine

CARLA version: 0.9.15
Platform/OS: Linux (Ubuntu22)
Problem you have experienced:
When I run packaged version in linux I get 2 fps.
I have the drivers of nvidia installed (nvididia-driver-535) and my pc is not that bad (nvme, intelcore i7 10th gen, nvidia gtx1660ti).
In windows, in the same machine, I can get easily 60 fps so the problem is not the hardware.
I have already tried the same thing on version 0.9.13 but I have the same problem.
Steps to reproduce:
Download the packaged version of carla
run ./CarlaUE4.sh -quality-level={Low}

I have a similar problem with the Carla simulator but with two Linux PCs. One with two 2080 TI and one with a 3090. Both have AMD Thread rippers inside. So I would say hardware is no Problem.
The PC with the 2080 runs smoothly with approx. 20 fps. The other one with 1-2 fps. This happens also in multi GPU mode in the first one with two 2080s. Something seems to be wrong here...

Are you sure that you are using your dedicated GPUs when running carla in linux?
You can set graphics card used by Graphics adapter with -graphicsadapter=1/2/3 , 0 may be indentified as integrated graphics adapter

Hello again, are you happy to close this issue?

Yes I'm sure. In nvtop I see either one card running normally or both cards running in multi GPU mode. In both cases with approx 40%.
To narrow the bug downthis happens only if LIDAR sensors are used, at least in my case.
I would not close an Issue if the error still persists, as it wouldn't make any sense.

This may be CPU related then. LIDAR is CPU based and uses tons of CPU.
Could you give more info about CPU?

Okay, I will try to do some tests when I get back in the office next week.

As there is no info we are gonna close this issue


chore: Cheaper integration tests

Avoid NAT gateways by just putting Fargate containers on a public subnet
👋 @QuinnyPig

Aw yiss


resolved chatbot overlapping bug #192

What does this PR do

This PR resolve the overlapping bug of chatbot.

Fixes #192
Tests Performed

Cleared all checks.
Done Default Formetting.

How Should this be tested.
Visit the chatbot, scroll to Testiomanials.
Updated Scrresnhot

@anujsingh4545 Kindly resolve conflicts


when will the full "modified cellular stack", thanks

the homepage said: "Upon request from the vendors, we are not releasing the modified cellular stack used in the FSM Inference module of our framework at this moment. "
As it has passed about half a year, could you release the full "modified cellular stack"?

Many thanks for your interest. We have been waiting for different vendors to complete the vulnerability patching process for all the different device models. The overall waiting period was unusually long and it is not possible to patch all the devices in the market. With this current situation, we have decided to open-source everything related to the project. We hope researchers will use the tool responsibly.


the exe crashed

Hi
i'm compile the code and run it on windows 8 32bit
but in the last step when generate the payload it's crashed

Hi,
Could you share the output or screenshot of the crash.

https://c.top4top.net/p_684idx7o1.png

any help ?

Now I tried again in Windows 7 SP1 32-bit  and Windows 8 32-bit/64-Bit, it worked without any problems.
Can you debug in Visual Studio and share more detailed information?

https://image.prntscr.com/image/d8MfayJlTKyRtrMP4u_O9A.png
https://image.prntscr.com/image/HeQkaS_KRa_84yye2izfKA.png
note: i have visual studio 2012

can you give me the compiled one ?

Hi i fix the problem Thanks

How did you fix the problem? Could it be useful for others, can you share?

@hlldz just change net framework of project from version 2 to version 4.5

Yes, I forgot to mention that. Thank you.


Protection

Continuing the discussion from https://github.com/mottosso/Qt.py/issues/152#issuecomment-263722786
Goal
Enable contributions from individuals who may not be able to guarantee full rights of his work to the recipient.
Motivation
In Open Source software, many lines of code come from external contributors. The target repository may be licensed under a free-for-all type license, but naturally each line of code written by a contributor defaults to being owned in its entirety by the contributor. It's basic copyright. Sometimes the basic copyright is overridden by a contract the contributor may have signed on accepting a job, in which case everything thing written by the contributor may belong to the company.
What this means for an Open Source repository is that some lines of code are licensed under e.g. MIT whereas other lines of code belong to various individuals and companies.
This wouldn't normally be a problem, if not for the fact that any of these individuals or companies may at any point decide to take action against either the individual who "leaked" proprietary information (or simply, time) or the repository for hosting this information.
Implementation
We need to find a way of enabling the contributor to provide copyrighted material into the repository, without becoming too much of an obstacle.
What are our options?
As far as I can tell, there are three options.

Use the Apache license (reference search for "CLA")
Use a Contribution License Agreement (CLA)
Use a Developer Certificate of Origin (DCO)

The Apache license includes a section (5) that implicitly confirms the transaction of IP from contributor to repository, but doesn't protect against if we later decide to change the license from Apache to something else, even MIT, in which case the code is no longer protected by this clause. It would be the simplest solution, as no extra work would be required on anyone's part.
A CLA means signing a document saying you give and are lawfully able to give the intellectual property (i.e. the source code) to the project. See OpenSubDiv for example. Then there are automated services (bots), like the CLAHub and CLA Assistant that keep track of who has signed a CLA and comments on a pull-request with a reminder to the contributor that signing is required.
The DCO is similar to a CLA, except you confirm your compliance to an external document in each pull request.
Docker was using a CLA, but nowadays (since 2014) uses a DCO. Here's what their contributor documentation has to say about it.

The sign-off is a simple line at the end of the explanation for the patch. Your signature certifies that you wrote the patch or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: if you can certify the below (from developercertificate.org)

Here's what that could look like in practice.

https://github.com/docker/docker/pull/28874

Discussion
Either of these approaches could work, my main objective is finding one that is least obstructive to making improvements to the project.
Switching to an Apache license have little other effect than introduce this new clause; it is as permissive as MIT if not more so. Introducing a CLA would require us (likely me) to keep track of signed documents, or use an external service to do so. A DCO is less work up-front, but potentially more work long-term; remembering to include that line of confirmation at each pull request, and for us maintainers to point out and remind those that forget.

Can't say for sure, but this suggests to me that one could implicitly accept a CLA simply by linking to and reading it.

https://cla.github.com/agreement

A CLA (or DCO, doesn't really matter which) is intended as a protection for what goes into an open source project.   It offers protections to those running open source projects from 3rd parties who might not even be using the project, but claim some kind of infringement.   By having the CLA or DCO you are making sure that each contributor attests that they have the rights to everything they are contributing.
The CLAs are more attractive to bigger companies than DCOs.  Companies typically don't give developers the rights to sign away ownership of code or other company assets.   This is an issue when the contribution was developed on company time.
Companies have mixed feelings about CLAs.  One advantage to them is that they put a roadblock in the way of developers just taking action without approval.  On the other hand, CLAs put protections in place for the OSS project and put more responsibility on the company.
I'm looking into the policy of a large company w.r.t. this.  I'll give a more definitive answer for one company when I have it.

Thanks @kgambrel, that's very helpful.

This one is tricky.

Enable contributions from individuals who may not be able to guarantee full rights of his work to the recipient.

@mottosso just curious, is this an existing problem in your company or at some studio you are aware of?

@mottosso just curious, is this an existing problem at a company you are aware of?

Did you mean to mention @melevine regarding https://github.com/mottosso/Qt.py/issues/152#issuecomment-263722786?
I have personally never experienced or seen this problem; I'd imagine it mostly relates to the really large firms (e.g. ILM) and open source projects (e.g. Docker) where the odds of being sued for copyright infringement is greater, and smaller shops and projects simply follow suit for defensive purposes.
@melevine or @kgambrel might be able to shed some more light on it.

Did you mean to mention @melevine regarding #152 (comment)?

Ah, yes. Sorry. Figured I'd ask someone who has experienced this first hand (or so) about what their suggestion/solution was. Has perhaps this already been discussed (can't recall or find anything right now).

@mottosso , w.r.t. the Github CLA, I'll check with out legal on it.   On first blush, it seems reasonable to me, as it's pretty much in line with the Apache CLA.  It is missing any mention of the possibility that one may be making a contribution from work done during employment by some other entity, but I'm not sure that makes much difference.   Thanks for pointing this out -- I was unaware of a default CLA.

Implemented, all pull-requests must now digitally sign the CLA before being merged. You'll be prompted when you make the pull-request, can't miss it.
Example

https://cla-assistant.io/mottosso/Qt.py?pullRequest=189


Network Instance State Collector

The process of collecting state data and metrics for network instances (IP assignments of app interfaces, interface metrics, application flows) has been previously scattered all across the zedrouter codebase. This commit consolidates stata data collecting into a standalone component defined by an interface NIStateCollector, meaning that the default Linux-based implementation is replaceable, which opens up the possibility of adding native support for other network stacks to EVE.
Another important goal of this refactoring was to simplify the existing implementation and make it easier to understand. Previously, state data were collected by multiple Go routines and exchanged through some additional channels and pubsub topics. It was quite difficult to understand the code as a whole and to see what actually is the intended behavior of some of its parts.

All relevant Yetus issues were fixed.

Did you consider the stutter yetus comment on line 29 in pkg/pillar/nistate/statecollector.go?

On second thought, I decided to do the renaming.

But do we have any tests which verifies that we get the status, metrics, and flowlogs somewhere?

In eden we do. However, these tests do not go very deep and do not cover all the fields of these published state data. After zedrouter refactoring I would like to have a look at eden tests and extend the existing ones plus add some more (for networking).


Add genre to ninjs

The whole list is here: http://cv.iptc.org/newscodes/genre/

    "genre": {
        "title": "Genre",
        "description": "A nature, intellectual or journalistic form of the content. nar:genre",
        "type": "array",
        "items": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "name": {
                    "title": "Name",
                    "description": "The name of the genre",
                    "type": "string"
                },
                "rel": {
                    "title": "Relationship",
                    "description": "The relationship of the content of the news object to the genre. Needed?",
                    "type": "string"
                },
                "scheme": {
                    "title": "Scheme",
                    "description": "The identifier of a scheme (= controlled vocabulary) which includes a code for the genre. Normally  http://cv.iptc.org/newscodes/genre/",
                    "type": "string",
                    "format": "uri"
                },
                "code": {
                    "title": "Code",
                    "description": "The code for the genre in a scheme (= controlled vocabulary) which is identified by the scheme property",
                    "type": "string"
                }
            }
        }

The above follow the structure for subjects etc.
One question is if an object can belong to more than one genre, or if genre is singular. If so we can remove the array.

To align with the NAR we should keep the array.
During the phone meeting on March 9th we decided that rel is not needed.

Just to have an example noted down, it would look like:
{
  ...
   "genre": [
      {
         "name": "Opinion",
         "scheme": "http://cv.iptc.org/newscodes/genre/"
         "code": "Opinion"
      }
   ],
   ...
}


useMediaQuery: unable to overwrite match on ssr with ssrMatchMedia

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior
Using ssrMatchMedia on useMediaQuery or in the theme makes no difference.
Expected Behavior
Should be able to apply my own logic inside that funciton to determine if a match should be made or not.
Context
I am using next.js with material. Given the nature of next, there's server side rendering in place.
In different parts of the application I use <Hidden> component as well as useMediaQuery.
I noticed that a particular part where I have a set of components wrapped in <Hidden smDown> flicker when the screen is loading: they take around a second to become visible (while on a resolution where they should be visible).
Upon investigating I found out that this problem happens also when you use the useMediaQuery hook so I ended up here https://next.material-ui.com/components/use-media-query/#server-side-rendering .
I implemented the ssrMatchMedia function to try and have a more precise match while on the server side so that I avoid this flickering, but I noticed the function is not doing anything.
On the same topic and while trying to understand the bug I am experiencing, I did this:
  const small = useMediaQuery(theme => theme.breakpoints.down('sm', {
    ssrMatchMedia: () => ({ matches: false }),
  }));

It is my understanding that this piece of code should always be false while on the server side. However a simple console.log shows that its value varies while being called with a series of different media queries.
As I understand, if I were to change matches: true it should always const small should always be true.
Steps to Reproduce
Being it depends on SSR,I dont know how I can help reproduce this. I can create a repository if it helps.
Your Environment
"@material-ui/core": "^4.9.1",
"next": "^9.5.3",
"react": "^16.13.1",

Chrome 80

@ybrodsky A couple of issues in the report:

You are using v4 as a dependency and the documentation of v5
ssrMatchMedia is only called for the initial hydration. Not for sequential rendering after hydration.
In order to work, the ssrMatchMedia implementation much account for the provided query. Such a query varies, especially when using the Hidden component.

I don't see the issue yet

@oliviertassinari thanks for the reply.
You are right about the doc, however that particular bit is the same https://material-ui.com/components/use-media-query/#server-side-rendering
As for the other points, if I add a log I can see that function is called several times with several different media queries until the final call where the media query is correct. That's what I assume causes the flickering of elements.
So do you have any idea why the sequential renderings after hydration are being called with a resolution that's not correct?

This is a valid issue report.
I found my project also exhibit the same issue with overrides.
I followed the doc for v9.11 at the moment.
https://material-ui.com/components/use-media-query/

I still don't understand what are the correct steps to reproduce for MUI useMediaQuery v4 + Next.js setup to avoid flickering. Instructions are unclear.
The documentation states that we should rely on theme breakpoints before using the user agents workaround. However, useMediaQuery is using those breakpoints.
Can someon clarify please?

avoid flickering

@RemyMachado TL;DR you can't: https://next.material-ui.com/components/use-media-query/#server-side-rendering.


non destructive functional tests

It introduces rkt run context which uses --dir, '--local-configand--system-config` flags to avoid using default values. So functional tests can be ran on local computer without worrying about messed up or deleted /var/lib/rkt or configuration.

Thanks for this! It looks cleaner now. I added a few comments.

Added some more commits on top.  :)

Just one nitpick about "Manual intervention", after that LGTM.


CLOUDP-192976: Unit test everything but int and e2e

This is an alternative to #1068 avoiding the use of build tags to achieve the same main goal.
It is a simpler change and we keep the project build tag free, but on the other hand, ´go test ./...´ will not work, as it will hit tests that are not expected to be run unless explicitly prepared (int and e2e).
All Submissions:

[X] Have you signed our CLA?
[ ] Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if there is one).
[ ] Update docs/release-notes/release-notes.md if your changes should be included in the release notes for the next release.

I might send an update for this, I think we can even get go test ./... to work by skipping the e2e and int test unless they are passed some env var.

Note if we take this route I need to make some changes to the wording at #1066

Will wait for #1079 and rebase after it lands


refactor: optimize simple bridge typescript and api server

cherry pick simple typescript commit to dapp-lib
add new privkey to api server

pay attention to new api server command args

#[derive(Clap, Clone, Debug)]
pub struct ServerArgs {
    #[clap(long, default_value = "~/.force-bridge/config.toml")]
    pub config_path: String,
    #[clap(long)]
    pub network: Option<String>,
    #[clap(short = 'c', long)]
    pub ckb_private_key_path: Vec<String>,
    #[clap(long, default_value = "5000")]
    pub lock_api_channel_bound: usize,
    #[clap(long, default_value = "0.9")]
    pub create_bridge_cell_fee: String,
    #[clap(short, long, default_value = "<IP_ADDRESS>:3030")]
    pub listen_url: String,
    #[clap(long, default_value = "mysql://root:@<IP_ADDRESS>:3306/serverdb")]
    pub db_path: String,
}

optimize api server and eth tx relayer

Codecov Report

Merging #202 (af8bcce) into dapp-lib (d3e1cbe) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##           dapp-lib     #202      +/-   ##
============================================
- Coverage     22.47%   22.45%   -0.02%
============================================
  Files            21       21
  Lines          4298     4301       +3
============================================
  Hits            966      966
- Misses         3332     3335       +3

Impacted Files
Coverage Δ

...ib/simple-eth-bridge-typescript-lib/src/adapter.rs
0.00% <0.00%> (ø)

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 b82cd13...af8bcce. Read the comment docs.


Fix elasticsearch result ids returning as strings

I am using the latest elasticsearch binary and master of nlp. For me elasticsearch searches failed because the resultant "id_" returned for searches are strings, but our library assumes them to be integers.

It looks like you need to rebase from master to fix the CI. Could you do that please ?


Negative Active cases Found

Describe the bug
The active cases are negative under some circumstances like Recovered cases become equal to Confirmed cases (eg) Thoothukkudi active cases column in the below image.
To Reproduce
Fix the minor arithmetic error.
Screenshots
See Thoothukkudi active cases column

Why do am I getting so many mails from COVID19 even after I have
unsubscribed the respective thing
On Fri, 1 May, 2020, 10:52 PM Mathana Kumar S<EMAIL_ADDRESS>wrote:

Describe the bug
The active cases are negative under some circumstances like Recovered
cases become equal to Confirmed cases (eg) Thoothukkudi active cases
column in the below image.
To Reproduce
Fix the minor arithmetic error.
Screenshots
See Thoothukkudi active cases column
[image: covidindiabug]
https://user-images.githubusercontent.com/36666781/80825490-1f38ed80-8bfe-11ea-943a-1f5353c958f0.jpg
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/covid19india/covid19india-react/issues/1698, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AOV23LG326GPJ2WKDTCADDLRPMAODANCNFSM4MXHTAQA
.

Issue has been fixed. TN was not publishing the data of the deceased and this lead to this discrepancy. Thank you for reporting. This does not require a front end fix as this is a data issue.


python38Packages.aiopvpc: 2.2.4 -> 2.3.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.aiopvpc is: "Python module to download Spanish electricity hourly prices (PVPC)"
meta.homepage for python38Packages.aiopvpc is: "https://github.com/azogue/aiopvpc"
meta.changelog for python38Packages.aiopvpc is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.3.0 with grep in /nix/store/75z6nq0x3d62kzsxmqy8znnlg72xxsg4-python3.8-aiopvpc-2.3.0

found 2.3.0 in filename of file in /nix/store/75z6nq0x3d62kzsxmqy8znnlg72xxsg4-python3.8-aiopvpc-2.3.0

Rebuild report (if merged into master) (click to expand)

7 total rebuild path(s)

4 package rebuild(s)

4 x86_64-linux rebuild(s)
3 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
docbookrx
home-assistant
python38Packages.aiopvpc
python39Packages.aiopvpc

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/75z6nq0x3d62kzsxmqy8znnlg72xxsg4-python3.8-aiopvpc-2.3.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.aiopvpc https://github.com/r-ryantm/nixpkgs/archive/60285371a6825fb5c693865050394cefa7034c2c.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/75z6nq0x3d62kzsxmqy8znnlg72xxsg4-python3.8-aiopvpc-2.3.0
ls -la /nix/store/75z6nq0x3d62kzsxmqy8znnlg72xxsg4-python3.8-aiopvpc-2.3.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

home-assistant

2 packages built:

python38Packages.aiopvpc
python39Packages.aiopvpc

Maintainer pings
cc @fabaff for testing.

Updated in  #151936


remove form_style from fieldset template

From what I see, form_style was removed from the main code and it does not appear in the corresponding template of crispy-bootstrap4.
I do not see any references in the current documentation either.
The name reference from template blasts debugging error output on my system.
Please consider removing the form_style.
PS
Mind the crispy-bootstrap4 does not use "safe" filters while the crispy-bootstrap5 does.

Good spot! Thanks. 🎁


any annontation equals @EnumId in lombok-pg

Really need another annotation for getting one of the Enum by it's field.
found @EnumId here:
http://peichhorn.github.io/lombok-pg/EnumId.html
Any lombok annotation equals to it? If not, any plan to support it?

Duplicate of #706


Need example code please.

I need example code, I dont understand anything with documentation only, i dont understand how I am supposed to understand how to use it. Can anyone please help me with example code for making call with sip.

You can't use the two test applications that are in the repository here?
https://github.com/AsterNET/AsterNET/tree/master/Asterisk.2013%2FAsterisk.NET.Test%2FAsterisk.NET.Test


Adds basic search screen

I'm going to generally avoid commenting on the UI specifically but speak more broadly: I would really much prefer us thinking about building very small reusable things and then composing them instead of styling everything inline like this.


regexp support look-around, including look-ahead and look-behind

Proposal:
use string regexp to filter metrics record, for example:
from(bucket: "tsdb_mysql")
|> range(start: 2022-08-10T06:50:00Z, stop: 2022-08-10T07:15:00Z)
|> filter(fn: (r) => (r._measurement == "mysql_global_status_queries" and r._field == "value") and r.hostname !~ /mgb-test(?!da01-dba|dp01-dba).*/)
Current behavior:
occured errror:  compilation failed: error @12:117-12:266: regex parse error: mgb-test(?!da01-dba|dp01-dba).* error: look-around, including look-ahead and look-behind, is not supported
Desired behavior:
flux string regexp support look-around, including look-ahead and look-behind.

@ZeroSean The Flux regexp implementation is built on top of the Go regexp implementation, which does not support look-around, look-ahead, or look-behind expressions. This is done for performance reasons. Because this is more of a Flux issue rather than an InfluxDB issue, I'm going to go ahead and close this issue.
You may consider opening a feature request on the Flux repo to add support for these expressions in the regexp implementation, but just know that this implementation was a conscious decision due to the performance impact of these types of expressions.


[Bug]: Not possible to select field of type Date in the Duplicate Search String Setup page

Describe the issue
Go to Marketing Setup > Related > Setup > Duplicate Search String Setup.
Click on field name:

In the lookup page that opens only fields of type Code and Text can be selected:

Is there any reason to add this restriction?
In NAV there were customizations made so that the users were able to select also field of type Date.
Now they want to upgrade to Business Central and it is not possible to migrate that customizations becase of the mentioned restriction.
Expected behavior
Posibility to select fields of type Date in the Duplicate Search String Setup page.
Steps to reproduce
Go to Marketing Setup > Related > Setup > Duplicate Search String Setup.
Click on field name:

In the lookup page that opens only fields of type Code and Text can be selected:

Additional context
In NAV there were customizations made so that the users were able to select also field of type Date.
Now they want to upgrade to Business Central and it is not possible to migrate that customizations becase of the mentioned restriction.

You can just request an event in this function, so you can change this filter yourself before the page opens.
You may also need to request other events at other points in the code.
table 5095 "Duplicate Search String Setup"
{
...
 procedure LookupFieldName()
    var
        "Field": Record "Field";
        FieldSelection: Codeunit "Field Selection";
    begin
        Field.SetRange(TableNo, DATABASE::Contact);
        Field.SetFilter(Type, '%1|%2', Field.Type::Text, Field.Type::Code);
        Field.SetRange(Class, Field.Class::Normal);
        if FieldSelection.Open(Field) then
            Validate("Field No.", Field."No.");
    end;
...
}

As an alternative to requesting events, you could make changes to the BaseApp in our BaseApp contribution pilot, if you think that this capability would be beneficial to all Business Central users.
You need to be granted access to the pilot repo, if you would like to collaborate on the BaseApp with us. To get access, please fill out the following form: https://forms.office.com/r/E9wyE5a58f.
Do you want me to transfer this issue to the BaseApp pilot repository?
Note, that the transferred issue would have to get approved in triage and you would have to create a pull request yourself. GitHub is not the right place to report issues you would like Microsoft to address. For that, please create a support request.
Alternatively, create an event request here on GitHub, and have Microsoft add the needed event for you.


Improves error handling in the case of missing type

This is for  https://github.com/launchbadge/sqlx/issues/239.
I didn't use the proposed error message in the issue because I'm not sure if there's an easy way differentiate between a missing user type and a typo. Although it does like that method should only be called in the context of new type names.
I haven't written much Rust and definitely have a couple of questions.
I don't really understand what's going on with the ? macro that pulls the oid out of the tuple automatically. I think my code would be a little clearer if I didn't need to leave the oid in a tuple
I'm also not sure if using map_error to mutate the error to the new TypeNotFound error is idiomatic
I'm not sure if this is worthy of a new error, and organizationally I'm not sure if it makes sense to have that type in sql-core when it currently only applies to postgres although i believe sql server also supports user defined types.
CC: @mehcode

@mehcode thanks for the feedback, I updated the PR and squashed into the original commit.

Awesome. Thank you.

Awesome. Thank you.


Title

/home/karan/Desktop/hbwapp/node_modules/whatwg-fetch/dist/fetch.umd.js:8
[0]     searchParams: 'URLSearchParams' in self,
[0]                                        ^
[0]
[0] ReferenceError: self is not defined
[0]     at /home/karan/Desktop/hbwapp/node_modules/whatwg-fetch/dist/fetch.umd.js:8:40
[0]     at support.searchParams (/home/karan/Desktop/hbwapp/node_modules/whatwg-fetch/dist/fetch.umd.js:2:66)
[0]     at Object. (/home/karan/Desktop/hbwapp/node_modules/whatwg-fetch/dist/fetch.umd.js:5:2)
[0]     at Module._compile (internal/modules/cjs/loader.js:702:30)
[0]     at Object.Module._extensions..js (internal/modules/cjs/loader.js:713:10)
[0]     at Module.load (internal/modules/cjs/loader.js:612:32)
[0]     at tryModuleLoad (internal/modules/cjs/loader.js:551:12)
[0]     at Function.Module._load (internal/modules/cjs/loader.js:543:3)
[0]     at Module.require (internal/modules/cjs/loader.js:650:17)
[0]     at require (internal/modules/cjs/helpers.js:20:18)

From https://github.com/github/fetch#read-this-first:

This project doesn't work under Node.js environments. It's meant for web browsers only. You should ensure that your application doesn't try to package and run this on the server.


Use object-assign for Node.js 0.12 support.

Closes #115.
We have a requirement to support Node.js 0.12 in Ember CLI, recent commits in tiny-lr which we adopted broke that. Rather than roll back, here's a PR to add back in Node.js 0.12 support so that we're able to fix forward.
Initial report: https://github.com/ember-cli/ember-cli/issues/6401
Assuming tests pass I'm hoping you can land this and release a new patch version!
Cheers!
Nathan, on behalf of the Ember CLI team.

Thank you!


New issues about the project

There are some errors when we try to connect the subpage to our main website, we need to double-check our code.

Yes, I also found that issue. And I will rewrite some code for our main page.


Create shriyadindi-12.md

@aslams2020 then why assign and waste time

@aslams2020 thats a scroll back button for the website, why should it not be considered??


Feature Request - Ajax autocomplete for Relationship fields

Right now, Voyager is using  tag for relationship fields. It loads all related objects as  tag in  tags.
It may cause problem when size of related model is very large i.e. it may cause problem in chrome when related model array is larger than 10,000. It may also decrease performance.
Voyager is using select2 jquery plugin and it supports remote loading of items through ajax.
Please make necessary changes.

Will this feature be available in version 1.0?

This likely still needs to be implemented, but I'm going to close it so we can have a fresh start following the 1.0 release.

what's up with this?


Make time format independant of selected language

Currently the time format used for the message at the bottom of each page, telling when the page was received, is set by language. This is kind of annoying since that means the only way to get 24-hour time is to set it to Interlingua or other languages I don't speak.

Hmm, I could add a 12/24 hour option here, or even a custom format string for the timestamp.
The page footer area needs a bit of improving in general, too.

24-hour time preference added for 1.9.1.


2.8.0: Error when calling DescribeInstanceTypes for instances t2.medium: You are not authorized to perform this operation.

Environment:

AWS ParallelCluster 2.8.0

Configuration file:

[aws]
aws_region_name = eu-central-1
[global]
cluster_template = default
update_check = true
sanity_check = true
[aliases]
ssh = ssh {CFN_USER}@{MASTER_IP} {ARGS}
[cluster default]
key_name = xxxxx
base_os = ubuntu1804
scheduler = torque
master_instance_type = t2.medium
compute_instance_type = c3.4xlarge
maintain_initial_size = true
vpc_settings = default
[vpc default]
vpc_id = vpc-xxxx
master_subnet_id = subnet-0bxxxx
compute_subnet_id = subnet-0dxxxxx
Bug description and how to reproduce:
After upgrade from 2.7.0 to 2.8.0 any pcluster command reports error:
$ pcluster list
ERROR: Error when calling DescribeInstanceTypes for instances t2.medium: You are not authorized to perform this operation.
No problems on the same setup in 2.6.1 and 2.7.0

Hi @tolid,
As part of 2.8.0 we improved the validations performed in the CLI and as a result of it a new policy is required when running pcluster create: "ec2:DescribeInstanceTypes". The full set of policies required by the latest version can be found here. Please let us know if you need further support.

Thank you @demartinofra
It works!


Observable on a loop

When i run the following code:
const tasks = new Listr([
	{
		title: 'download',
		task: () => {
			return Observable.create(async observer => {
				let {photos, title} = await collectionDownloader(562095);

				photos.forEach(async ({url, id}, index) => {
					let pth = join(__dirname, title);
					mkdp.sync(pth);
					pth += `/${id}.jpg`;

					const file = fs.createWriteStream(pth);

					https.get(url, response => {
						response.pipe(file).on('finish', () => {
							observer.next(`Downloading ${index + 1} of ${photos.length} photos from ${title}`);
							file.close();
						});
					});

					if (index === photos.length) {
						return observer.complete();
					}
				});
			});
		}
	}
]);

tasks.run();

i get this:

The problem

it never ends.
the index is not correctly shown.. is not ordered and it starts when all downloads are done..

Please tell me what I'm doing wrong.

Probably because index is zero based and photos.length is one based. So basically, you're checking 14 === 15.
Support questions are better asked on StackOverflow. This has (probably) nothing to do with Listr itself.


OpenXR: inconsistent results with pose recenter

Tested versions

Reproducable in 4.3-stable
Reproducable in 4.4-dev cb411fa960f0b7fdbd97dcdb4c90f9346360ee0e

System information
Any
Issue description
XR headsets have long had a build in feature to recenter our view but the definition of how we should react to this under different conditions has been somewhat unclear. Recently behaviour around this has changed in various XR runtimes with the introduction of the new 'LOCAL_FLOOR' reference space and with that the interpretation of the 'STAGE' reference space changing.
Currently what we do is completely broken with us no longer sending 'recenter' events to the user so this needs to be fixed, but there are further problems with our implementation.
First, as mentioned, different XR runtimes interpret how to react to the user triggering a recenter differently. As we're only indirectly informed of this through the XR_TYPE_EVENT_DATA_REFERENCE_SPACE_CHANGE_PENDING event, this is where we're reacting to this, but us reacting to this is being ignored because the contents of this event seems to have changed.
Second, different XR runtimes interpret the rules differently. Quest sends out a single event, while steamVR sends multiple.
Third, timing is wrong, this is a pending event telling us that the stage change will soon be applied and depending on how we react to the signal, in its current implementation we get the signal before we read the new tracking data.
We should probably change this logic in the following ways:

ignore the poseValid property of the event
set a flag "pose_is_recentered" to true on receiving this event
check the flag AFTER we obtain new tracking data and then emit the pose_recentered signal and reset the flag

Steps to reproduce
This can be reproduced in the character centric movement demo on our demo repository though I need to submit a few fixes which I'll do momentarily (the current recenter logic is incorrect as it does not take the chosen reference space into account).
Then simply trigger a recenter:

In steamVR, open the steamVR menu and choose recenter
In Quest (link or native) hold the meta button for a few seconds
Consult manual for other platforms.

Minimal reproduction project (MRP)
https://github.com/godotengine/godot-demo-projects/tree/master/xr/openxr_character_centric_movement

cc @dsnopek @Malcolmnixon


Is this ready for use in my prototype crypto code?

Hi, Thomas.  I would like to use this code in a prototype crypto-related project that wont go live in 2018 (though the prototype should be functional in 2018).  The earliest that products using this code could possibly launch might be late 2019.  In your opinion, is it OK for me to be an early adopter of CTTK?  You've seen enough of my code to know that while I understand what I'm doing, I do make mistakes.  My alternative is to roll-my-own to a certain extent, as no other bignum library I've seen was designed from the ground up for constant-time operation.

From my point of view, the code that is in CTTK is about as ready as it can be. It has comments and tests; there is nothing much to add at that point, except external uses . The library itself is said to be in "beta" state because it is quite incomplete (i.e. there are other features that I plan to add). However, what is implemented right now should be "fine" (i.e. I am reasonably happy with the API as it is now, so unless library users find problems with it, the API should not change).

Hi, Thomas.  We need to support constant-time operations on integers modulo odd numbers.  In particular, don't we want Montgomery multiplication?  Several other modular arithmetic constant-time operations are likely needed as well.
I'd be happy to write them, if you have time to suggest algorithms, and review my code.

Right now there is no support for modular integers in CTTK. I do have code for that; it is in BearSSL:
https://www.bearssl.org/
(specifically in the src/int/ directory). Importing that code into CTTK is doable but it will require a bit of thinking to design a proper API (the BearSSL code is internal, thus it can tolerate an unforgiving API with merely documented assumptions on correctness of operands). I'll do that as time allows (I am just back from holiday and I expect a couple of weeks of getting things in order first).

Awesome.  In the meantime, we'll just emulate modulo operations using double-width integers and the existing constant-time mod operation.  We'll drop in your upgrade when available.


Timeout occurring when it shouldn't

I got a situation where the timeout is thrown even though the duration between event emission is lesser than it.
This issue occurs because of the combination of the delay of the "for await of" operation and the timeout itself.
I was able to create a test case where this issue happens
    it("should not throw timeout for delays caused by the 'for await of' using the generated Async Iterable", async () => {
      const emitter = new EventEmitter();

      const iterator = forEmitOf<{ message: string }>(emitter, {
        firstEventTimeout: 100,
        inBetweenTimeout: 100,
      });

      setTimeout(async () => {
        emitter.emit("data", { message: "test1" });
        emitter.emit("data", { message: "test2" });
        await sleep(80);
        emitter.emit("data", { message: "test3" });
        await sleep(80);
        emitter.emit("data", { message: "test4" });
        emitter.emit("end");
      }, 10);

      let result = "";

      for await (const chunk of iterator) {
        await sleep(50);
        result += chunk.message;
      }

      expect(result).to.equal("test1test2test3test4");
    });

@Farenheith  Nice 😎


LOGICAL_AND" : &&

hey hii ... i would to work on this task if possible !

I would appreciate the opportunity to take on this task. Please consider assigning it to me, as I am confident in my ability to handle it effectively.

LOGICAL_AND" : && pls assign me @samthakur587

Hi @NripeshN,
I would like to contribute to this issue by implementing support for the LOGICAL_AND operator in the DirectX backend. Could you please assign this issue to me?
Thank you!


jenkins: clang tidy retry

Describe problem solved by the proposed pull request
https://github.com/PX4/Firmware/issues/10678
e.g. http://ci.px4.io:8080/blue/organizations/jenkins/PX4%2FFirmware/detail/PR-10414/8/pipeline
Describe your preferred solution
Retry the step (up to 3 total runs).
Describe possible alternatives
Retry a different amount of times?
Additional context
I also moved the make distclean steps to post conditions which are guaranteed to execute regardless of build stage result.

Also, should the catkin build belong in the compile job? I can move that after this PR.

should the catkin build belong in the compile job

I don't know, it's kind of a special case that doesn't fit with anything else. Moving "Catkin" and "unit tests" to the SITL tests build stage could be okay.