avoid casts on calls to mock methods

For example:
  class Monster {
    // Returns current health after applying [hp] damage to this monster.
    int damage(int hp);

    // Returns current health after applying [f()] damage to this monster.
    int damageFromClosure(int f());
  }
  class MockMonster extends Mock implements Monster {}

  var mock = new MockMonster();
  when(mock.damage(argThat(isPositive))).thenReturn(100);
  when(mock.damageFromClosure(argThat(isFunction))).thenReturn(200);

We'll want to allow mock.damage to avoid the cast to int. This is safe because when using nSM to implement abstract methods, the method is conceptually implemented by a method that forwards to nSM, and that method can widen the argument types to Object.

Hey @leafpetersen ... I just thought of an interesting complication here. Continuing my example above, we'd have to know to disallow this kind of override:
class DerivedMockMonster extends MockMonster {
  // override error: int -> int is not a subtype of Object -> int from MockMonster
  int damage(int hp) => hp.isEven ? 0 : 1000;
}

... because that would tighten up the parameter type.
If we day nSM "implements" all abstract methods and widens parameter types to Object, we could do it, but it disallows overrides later on.
Implementation wise, we'd want to track the induced members explicitly in the element model as synthetic ones. So a bit tricky.
But conceptually I'm not sure how I feel about it. Is it too restrictive? Using nSM becomes kind of dangerous as it will silently "widen" your abstract members.
Perhaps a better pattern is to alter the mock package API:
verify(mock).damage(argThat(isPositive)).thenReturn(100);
verify(mock).damageFromClosure(argThat(isFunction)).thenReturn(200);

By wrapping the mock object it's possible to accept different signatures. I would assume Java Mockito has a similar issue, for the same reasons we do.

My initial (somewhat tentative) thinking was that this wouldn't be the default behavior, but something you opted into via an annotation or syntax at the NSM declaration site.  So a standard NSM codegens with the right signature, but if you put the annotation there (@Widen?) then it codegens with the widest possible signature.  This does forbid narrowing it again - does that matter for our use case?  My thinking was not.  If it does, then we could basically use the same mechanism as our planned covariant override support to allow re-narrowing.

For some context, the DerivedMockMonster
class DerivedMockMonster extends MockMonster {
  // override error: int -> int is not a subtype of Object -> int from MockMonster
  int damage(int hp) => hp.isEven ? 0 : 1000;
}

is an example of mixing faking and mocking, which is a highly discouraged pattern. The damage override will take precedence on any stubbing, which can lead to hard to debug tests. The recommended way would be to set common behavior in the setUp of the test:
setUp(() {
  when(mockMonster.damage(any)).thenAnswer((int hp) => hp.isEven ? 0: 1000);
});

For the mocking use-case, I don't believe preventing narrowing again is an issue.

@thso @leafpetersen do y'all like the opt-in annotation idea? It would only need to appear on the nSM, so derived classes don't need to worry about it:
class Mock {
  // ...
  @SomeAnnotationHere()
  noSuchMethod(Invocation invocation) { /* ... */ }
}

Any naming ideas? Since it's not going to occur very frequently something that feels more explanatory might be preferable to a really short name, e.g. @allowAnyArgumentType  or @noCastsOnArguments ...
Alternatively we could make it the default, and let the covariant overrides feature be used for narrowing, if that's ever needed. It sounds like it isn't needed for mockito, and I think they are one of the main users of nSM.

Yes, I'm in favor.  Perhaps @WidenParameters, or just @Widen?

I'm in favor of making it optional, I don't think it's a behavior one would expect in other circumstances. @WidenParameters looks good to me!

sounds good to me!
fyi, this is kind of blocked for the same reason as:
https://github.com/dart-lang/sdk/issues/25578#issuecomment-239973208
... but as soon as we get that resolved (one way or the other) I can take a look

sent out patch for 25578 so picking this one back up

actually ... going to wait for that patch to land so I can build on it. The CL for it is https://codereview.chromium.org/2336503003/

Thanks @jmesserly! Would you have some vague ETA on this?

thanks for the ping. I need to think it over again to see if there's a nice way of implementing it. Even after the 25578 fix, it didn't seem clear how we can fit it in nicely. But in the meantime I've been trying to (slowly) get things into a more hackable state. Stay tuned.

@thso  This is proving a bit complex to implement, I'd like to get a sense of how much this is a blocker for things we need, and how much this is a nice to have (and if the former, how urgently).

ping, are we still interested in a feature like this? I think it would be challenging to have to implement it in both CFE and Analyzer at this point. Assuming stale, but let me know if we should reopen


Not able to make it work

Sorry for bothering, but I'm just not able to get this work.
I'm on CentOS7 with Docker 1.13.1.
My /etc/docker/daemon.json looks like this:
{
"ipv6": true,
"fixed-cidr-v6": "fd00:172:17:1::/64"
}

I've created the the ipv6nat like this:
docker create \
	--name ipv6nat \
	-v /var/run/docker.sock:/var/run/docker.sock:ro \
	-v /lib/modules:/lib/modules:ro \
	--net=host \
	--cap-add=NET_ADMIN \
	--cap-add=SYS_MODULE \
	--restart unless-stopped \
	robbertkl/ipv6nat

Is this enough? Should this now work out of the box?
I don't see any differences. What am I supposed to do to make the natting work?
If I create a container like this, nothing changes compared to without ipv6nat:
docker create \
	--name=somedocker\
	-p 1199:8888 \
	--restart unless-stopped \
	something/fromdocker

Please check the output of ip6tables-save (either on the host or within the ipv6nat container). If it works correctly it should show the created NAT rules here.
Also make sure you're not binding to a specific IPv4 address, just a port, but I see you've already edited your text to reflect this.

Can you run the binary without docker and pass the -debug flag? This should print out all rules changes performed by docker-ipv6nat.

Please check the output of ip6tables-save (either on the host or within the ipv6nat container). If it works correctly it should show the created NAT rules here.
Also make sure you're not binding to a specific IPv4 address, just a port, but I see you've already edited your text to reflect this.

You are right, I see something if I remove the static ip-address from the -p option.
-A DOCKER -p tcp -m tcp --dport 1199 -j DNAT --to-destination [fd00:172:17:1:0:242:ac11:8]:8888
But in case I want the port to be bind to a special ipv6 address. How can I do that. Is that supported?
Things like -p [ipv6:address]:123:456 aren't working because docker complains on run (not creation)

Unfortunately, this is not possible, as it would require built-in support from Docker.
You could use com.docker.network.bridge.host_binding_ipv6 on a user-defined network (see README), but that might not be what you want.

Unfortunately, this is not possible, as it would require built-in support from Docker.
You could use com.docker.network.bridge.host_binding_ipv6 on a user-defined network (see README), but that might not be what you want.

OK. Thank you anyway. I'll figure something out...
Anyways. Nice tools ;-)

Cool, good luck!

You are right, I see something if I remove the static ip-address from the -p option.
-A DOCKER -p tcp -m tcp --dport 1199 -j DNAT --to-destination [fd00:172:17:1:0:242:ac11:8]:8888
But in case I want the port to be bind to a special ipv6 address. How can I do that. Is that supported?
Things like -p [ipv6:address]:123:456 aren't working because docker complains on run (not creation)

I am using Debian 9 and Debian 10 with the official Docker CE distribution and Docker-IPv6NAT. If I specify a static IPv6 address for a published port by --publish, a DNAT rule is created for IP6Tables.


Everything You Wanted to Know About Blockchain in One Infographic

https://futurism.com/artificial-intelligence-hype?utm_source=Digest&utm_campaign=95f865d6cd-EMAIL_CAMPAIGN_2018_10_16_06_09&utm_medium=email&utm_term=0_03cd0a26cd-95f865d6cd-246370613&mc_cid=95f865d6cd&mc_eid=50bd36f041


Propagate API keys to dataviews in public API

Related to https://github.com/CartoDB/cartodb.js/issues/2071
This PR propagates the credentials set in carto.client to dataviews. It fixes a bug, where the dataviews didn't had the API key and then they build URLs with no keys.
Acceptance
Public API

Create all type of widgets against a private dataset.
Use an API key [1] with SQL select and MAPS permission for that dataset.
Check that the widgets return data. No 403 must be received.
Create all type of widgets against a public dataset.
Use the default_public key.
Check that widgets work.

Builder

[ ] Generally speaking, check that widgets behave.
[ ] In Builder, create several type of widgets. They must be created with no problem and filters should work.
[ ] In Category widgets, perform a search.
[ ] Publish the map
[ ] Interact with the widgets. They should work as always.
[ ] To test Auth tokens

[ ] In a organization, share a private map with all type of widgets with a colleague.
[ ] Seeing the map with the colleague profile, check in the URLs that the widgets are requested using auth tokens.
[ ] Widgets should work as always.

Mock unification being done at https://github.com/CartoDB/cartodb.js/pull/2076


Unable to remove Enterprise Domain Controller Group from the policy

[Enter feedback here]

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

ID: 26371c81-f040-cb55-43d3-c923ae5f5f6a
Version Independent ID: bdfe2a76-c085-cfae-e676-6bc037e74fea
Content: Access this computer from the network - security policy setting (Windows 10)
Content Source: windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md
Product: w10
Technology: windows
GitHub Login: @Dansimp
Microsoft Alias: dansimp

@yckwan
Your feedback is missing content. Would you be able to clarify the product documentation issue in relation to the associated article? We would like to follow up. Thanks.


Setting CSS preprocessor corrupts the environment settings

OS?

Mac OSX El Capitan

Versions.

angular-cli: 1.0.0-beta.25.5
node: 4.2.6
os: darwin x64
@angular/common: 2.4.3
@angular/compiler: 2.4.3
@angular/core: 2.4.3
@angular/forms: 2.4.3
@angular/http: 2.4.3
@angular/platform-browser: 2.4.3
@angular/platform-browser-dynamic: 2.4.3
@angular/router: 3.4.3
@angular/compiler-cli: 2.4.3

Repro steps.

Just create a new project and change the CSS preprocessor using cli:
ng set defaults.styleExt sass
but this corrupts environments settings in angular-cli.json:

This looks like a bug, thanks for reporting it!
@hansl this looks like an unintended side-effect of the new @ngtools/json-schema.

same issue I am facing !!

I just ran into this last night, glad to see someone reported it already. Thanks!


Rename "private messages" to "direct messages"

In https://github.com/zulip/zulip/pull/24224 and follow-up work, we renamed "private messages" to "direct messages" in the web app. We should do the same in the mobile app. This issue is specifically for user-facing stings.
The mobile instructions on /help/direct-messages and in /help/include/send-group-dm.md will need to be updated accordingly, either as part of this issue, or as an immediate follow-up.

This issue is specifically for user-facing strings.

Just to underline this part: let's defer any renames or other refactoring, leaving non-user-facing uses of "private" alone for now.


Readme does not talk about line endings in answer file

Need to ensure that user is aware they need to save answer files with LF endings rather than CRLF. Recommend VS Code.

I actually ran into this. A hint in the readme would be nice.


fix(radio-button): add missing slot optioin

Related Ticket(s)
Closes #11288
Description
fixes slot for radio-button
Changelog
New

{{new thing}}

Changed

accidentally got removed .... but adding <slot> around ${labelText}

Removed

{{removed thing}}

@ariellalgilmore I just see you release<EMAIL_ADDRESS>Shouldn't this have this PR? It seems that he has not been part:
https://github.com/carbon-design-system/carbon-for-ibm-dotcom/commits/%40carbon/web-components%402.1.2/
Thanks!

Since there is a workaround, this PR will go into the next release. We start code freeze on the next release this Friday

For our case there is no workaround: https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/11288#issuecomment-1875833213
But ok, we can wait until next release.


Javascript error when updating table display (PR #87 export-data)

Re: PR https://github.com/microscopium/microscopium/pull/87
I'm getting a javascript error related to updating the datatable with selected data from the scatterplot. It doesn't seem like a fatal error, but should still be fixed:
error handling message Message 'PATCH-DOC' (revision 1): DeserializationError("Seq(Any) expected a list or None, got {'0': -0.43731416321298383, '1': -0.4933948783766794}",)
Plan of attack - set the table.source to a CDSView of the scatterplot source selected indices.
Some other possibly related info:

https://github.com/bokeh/bokeh/issues/7417#event-1898832123
https://github.com/bokeh/bokeh/pull/8310

Those are definitely the relevant issue/PR. The work has been merged and those error messages should go away with the next release of Bokeh. If you'd like to try things out early, dev builds are installable now: https://bokeh.pydata.org/en/latest/docs/installation.html#developer-builds

So I just tried adding https://github.com/bokeh/bokeh.git to the pip install section of ourenvironment.yml but conda had trouble unpacking bokeh. Not sure if I've done something silly because I'm tired, but I thought that should have worked.
environment.yml file:
name: mic
dependencies:
- python=3.6*
- click
- cytoolz
- h5py
- matplotlib
- networkx
- numpy
- pandas
- pip
- pymongo=3*
- scikit-image
- scikit-learn
- scipy
- setuptools
- six
- toolz
- imageio
- pip:
  - coverage>=4.0
  - pytest>=2.8
  - pytest-cov>=2.2
  - sh>=1.11
  - https://github.com/bokeh/bokeh.git

Traceback:
$ conda env create -f environment.yml
Solving environment: done

==> WARNING: A newer version of conda exists. <==
  current version: 4.5.10
  latest version: 4.5.11

Please update conda by running

    $ conda update -n base -c defaults conda

Downloading and Extracting Packages
wheel-0.32.1         | 35 KB     | ##################################### | 100%
scikit-learn-0.20.0  | 5.4 MB    | ##################################### | 100%
numpy-base-1.15.2    | 4.1 MB    | ##################################### | 100%
cloudpickle-0.5.6    | 26 KB     | ##################################### | 100%
matplotlib-3.0.0     | 6.8 MB    | ##################################### | 100%
tornado-5.1.1        | 662 KB    | ##################################### | 100%
networkx-2.2         | 2.0 MB    | ##################################### | 100%
pyparsing-2.2.2      | 97 KB     | ##################################### | 100%
cytoolz-<IP_ADDRESS>      | 350 KB    | ##################################### | 100%
pymongo-3.7.1        | 990 KB    | ##################################### | 100%
dask-core-0.19.3     | 1.2 MB    | ##################################### | 100%
pillow-5.3.0         | 550 KB    | ##################################### | 100%
pywavelets-1.0.1     | 4.3 MB    | ##################################### | 100%
numpy-1.15.2         | 48 KB     | ##################################### | 100%
mkl_fft-1.0.6        | 139 KB    | ##################################### | 100%
six-1.11.0           | 21 KB     | ##################################### | 100%
click-7.0            | 118 KB    | ##################################### | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
Collecting https://github.com/bokeh/bokeh.git (from -r /Users/genevieb/Documents/GitHub/Code_repositories/microscopium/condaenv.9_lsiz22.requirements.txt (line 5))
  Downloading https://github.com/bokeh/bokeh.git
     / 245kB 93kB/s
  Cannot unpack file /private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-unpack-jave95nr/bokeh.git (downloaded from /private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-req-build-olw3aj30, content-type: text/html; charset=utf-8); cannot detect archive format
Cannot determine archive format of /private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-req-build-olw3aj30

CondaValueError: pip returned an error

Should be git+https

Thanks! I knew it'd be something silly.
Unfortunately there is a user input prompt that seems to be broken, I can't pip install:

adding git+https://github.com/bokeh/bokeh.git to the environment.yml file
from the terminal into an existing conda environment with pip install git+https://github.com/bokeh/bokeh.git
locally from my cloned bokeh repository, with pip install .

Same traceback and error message each time:
$ conda env create -f environment.yml
Solving environment: done

==> WARNING: A newer version of conda exists. <==
  current version: 4.5.10
  latest version: 4.5.11

Please update conda by running

    $ conda update -n base -c defaults conda

Preparing transaction: done
Verifying transaction: done
Executing transaction: done
Collecting git+https://github.com/bokeh/bokeh.git (from -r /Users/genevieb/Documents/GitHub/Code_repositories/microscopium/condaenv.8ikywm76.requirements.txt (line 5))
  Cloning https://github.com/bokeh/bokeh.git to /private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-req-build-l3mtj88r
    Complete output from command python setup.py egg_info:

    Bokeh includes a JavaScript library (BokehJS) that has its own
    build process. How would you like to handle BokehJS:

    1) build and install fresh BokehJS
    2) install last built BokehJS from bokeh/bokehjs/build

    Choice? Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-req-build-l3mtj88r/setup.py", line 109, in <module>
        bokehjs_action = build_or_install_bokehjs()
      File "/private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-req-build-l3mtj88r/_setup_support.py", line 128, in build_or_install_bokehjs
        jsbuild = jsbuild_prompt()
      File "/private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-req-build-l3mtj88r/_setup_support.py", line 253, in jsbuild_prompt
        value = input("Choice? ")
    EOFError: EOF when reading a line

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/gz/6f0v_zhs09x38mb4td_h6py80000gn/T/pip-req-build-l3mtj88r/

CondaValueError: pip returned an error

@GenevieveBuckley check out the link shared by @bryevdv. Looks like building Bokeh is quite tricky so they provide prerelease conda and pip packages. The installation from source instructions are quite unconventional!
https://bokeh.pydata.org/en/latest/docs/dev_guide/setup.html#devguide-setup

Good point, reading the documentation would be a good start.
Ok, so I can get a bokeh development install working well using the steps from your link here: https://bokeh.pydata.org/en/latest/docs/dev_guide/setup.html#devguide-setup
I've tested it like they suggest you do at the end, and both examples with the sample data work well.
I've also been able to create a new microscopium conda env with a bokeh development install. The bokeh sample data tests work.
In the old microscopium conda env (using bokeh 0.13) I can run python microscopium/serve.py tests/testdata/images/data.csv and everything works.
But... putting the last two bits together is a problem. Once I switch to the conda env with the development version of bokeh, our web app no longer updates the figure with the selected images. To make things trickier, there are no python or javascript errors being reported.
$ python microscopium/serve.py tests/testdata/images/data.csv
ready!
WARNING:bokeh.server.util:Host wildcard '*' will allow connections originating from multiple (or possibly all) hostnames or IPs. Use non-wildcard values to restrict access explicitly

Javascript logs:
properties.js:14 [bokeh] setting log level to: 'info'
connection.js:183 [bokeh] Websocket connection 0 is now open
data_table.js:180 [bokeh] jquery-ui is required to enable DataTable.reorderable
document.js:162 [bokeh] document idle at 358 ms
notebook.js:60 Bokeh items were rendered successfully

@GenevieveBuckley Yikes! That's scary, and suggests that whatever we're doing in 0.13 might go away soon. =(

@jni @GenevieveBuckley This patch appears to be what is needed to get things working with 1.0dev builds:
diff --git a/microscopium/serve.py b/microscopium/serve.py
index b13fbdc..309cbb6 100644
--- a/microscopium/serve.py
+++ b/microscopium/serve.py
@@ -300,17 +300,17 @@ def make_makedoc(filename, color_column=None):

         def load_selected(attr, old, new):
             """Update images and table to display selected data."""
-            print('new index: ', new.indices)
+            print('new index: ', new)
             # Update images & table
-            if len(new.indices) == 1:  # could be empty selection
-                update_image_canvas_single(new.indices[0], data=dataframe,
+            if len(new) == 1:  # could be empty selection
+                update_image_canvas_single(new[0], data=dataframe,
                                            source=image_holder)
-            elif len(new.indices) > 1:
-                update_image_canvas_multi(new.indices, data=dataframe,
+            elif len(new) > 1:
+                update_image_canvas_multi(new, data=dataframe,
                                           source=image_holder)
-            update_table(new.indices, dataframe, table)
+            update_table(new, dataframe, table)

-        source.on_change('selected', load_selected)
+        source.selected.on_change('indices', load_selected)
         page_content = layout([
             [embed, image_plot],
             controls,

apologies for the churn, we all make mistakes unfortunately, but at least there are tests in place now to maintain that this kind of pattern always works as expected.

@bryevdv Great! Thank you so much for looking at this! We will pin to 0.13 for now and keep this patch and issue in mind for when it's time to upgrade.
Incidentally, we ourselves are not testing any Bokeh functionality as we have no experience with writing UI tests. So if you can point us to anything you're doing that we could maybe implement for our own tests, that would be incredibly useful!


Is there a way to open DevTools progammaticaly?

Puppeteer version: v0.12.0-alpha
Platform / OS version: Windows 7 x 64

These hotkeys seem not to work:
  page.press('F12');

  // or

  page.keyboard.down('Control');
  page.keyboard.down('Shift');
  page.keyboard.down('I');
  page.keyboard.up('I');
  page.keyboard.up('Shift');
  page.keyboard.up('Control');

@vsemozhetbyt I don't think there's a way now. Why would you want this?

@aslushnikov To save some actions on debugging.
Does contents.openDevTools([options]) in Electron uses something unavailable for DevTools protocol?

Does contents.openDevTools() in Electron uses something unavailable for DevTools protocol?

I believe this is a c++ binding to devtools_window.
I just figured there's a chromium flag for this: --auto-open-devtools-for-tabs.
If you have time, I'd appreciate a PR that adds devtools option to the puppeteer.launch, nightmare has it.

Hey, I found this as a good solution.
await puppeteer.launch({ devtools: true });
this also forces the headless mode false.
found in the docs for v1.7. https://github.com/GoogleChrome/puppeteer/blob/v1.7.0/docs/api.md#puppeteerlaunchoptions

Also It would be amazing if you could add a new param for opening particularly tab e.g. 'Console' or 'Network'

@max-buranbaev why do you guys want some specific panel opened? What's your workflow?

@max-buranbaev why do you guys want some specific panel opened? What's your workflow?

@aslushnikov Here's my use case for this feature: displaying the console messages while running Cypress.io tests. Cypress is a great tool, but it lacks a way of getting the console logs of an automated test run, which makes errors that only occur in CI difficult to debug.
By opening devtools with the console panel at Cypress startup, the console logs would be visible in the video recording Cypress generates (https://docs.cypress.io/guides/core-concepts/screenshots-and-videos.html)

Opening devtools with console panel open would be great indeed.

For me this
const SETTINGS = {
    headless: false,
    userDataDir: './data',
    args: ['--no-sandbox', '--disable-setuid-sandbox', '--auto-open-devtools-for-tabs' ]
}

is working.
Chromium remembers the last tab. It's not the 'perfect' solution, but it works :+1:
I need the network tab open before the page load (else I need to reload the page again...)

@mihaimartalogu I have that exact same use case. Would be awesome if there was a way to default to a certain tab in dev tools so I can see it recordings.

@mihaimartalogu I got a little bit closer with this https://github.com/GoogleChrome/puppeteer/issues/3699
It gives me another browser tab that I can switch to/from and can use puppeteer keyboard commands to switch to the console pane.

i was able to open devtools the default Elements tab, how can i switch to console tab to send commands. anyone ?

I have a use-case where I have to inject some script in the DOM & run some JS. Did anyone solve this?

@supdev1111 Closest I got was with this here https://github.com/GoogleChrome/puppeteer/issues/3699 Gives you a tab in chrome that is the devtools for another tab. Then you can issue puppeteer commands to it just like any other page. Not perfect because I have to write statements into my test to switch tabs at the right time to catch console logs in a video during test.

what class or object does contents.openDevTools() belong to exactly???

@max-buranbaev why do you guys want some specific panel opened? What's your workflow?

I'm building an internal developer tool which logs to the console. I'd like to add a "logs" button in the app which pops open the chrome developer tools to the console tab. That way it's less confusing for people who have never used the app before.
Sure I can go through the trouble of creating my own "logs page" inside the application but that's a lot of work for what i'm building; I'd rather just call console.log.

Stumbled upon this again 😂
Would love to have Console tab open directly instead of doing it manually all the time :)

Is there a way to open DevTools of the DevTools tab?
Need it to capture websocket frames: https://gist.github.com/signed/68f61bbebdd3375d6463d12d68e5a299

Sat Nov 26, 2022
Still can't find a way to open console tab directly... 😂
3 days walking around on google 🥲

I need to open the network tab, guys :D

the following is working for me:
	const targets = await browser.targets();
	const devtoolsTarget = targets.find((t) => {
	  return t.type() === 'other' && t.url().startsWith('devtools://');
	});
	const client = await devtoolsTarget.createCDPSession()
	await client.send('Runtime.enable');
	await client.send('Runtime.evaluate', {
		expression:`
			window.UI.viewManager.showView("network");
			window.UI.dockController.setDockSide("bottom")
		`
	});

@matt- it did not work for me :/

This should work if you are using Linux :
exec('xdotool getactivewindow key ctrl+shift+i', (err) => {
});


Test suite broken in 0.0.25

Hi,
I'm totally newbie and just tried this library "out of the box" on Win8.1.
Noticed that Test Suite referenced from run.bat seems to be broken in the last version (0.0.25).
Probable cause: recent changes to use LastErrorException?
TestFreeFormPortIdentifiers.testMissingPortInCommPortIdentifier() seems to expect NoSuchPortException but that is no longer thrown?
Version 0.0.23 jar works. Below output when using 0.0.25.
PureJavaComm Test Suite
Using port: COM1
TestMissingPort                               jtermios.windows.JTermiosImpl$Fail
    at jtermios.windows.WinAPI$Windows_kernel32_lib_Direct.CreateFile(Native

Method)
at jtermios.windows.WinAPI.CreateFile(WinAPI.java:584)
at jtermios.windows.JTermiosImpl$Port.open(JTermiosImpl.java:140)
at jtermios.windows.JTermiosImpl.open(JTermiosImpl.java:353)
at jtermios.JTermios.open(JTermios.java:389)
at purejavacomm.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.
java:101)
at purejavacomm.testsuite.TestFreeFormPortIdentifiers.testMissingPortInC
ommPortIdentifier(TestFreeFormPortIdentifiers.java:25)
at purejavacomm.testsuite.TestSuite.main(TestSuite.java:43)
Caused by: java.lang.RuntimeException: [2]Määritettyä tiedostoa ei löydy. getLas
tError=0
at jtermios.windows.JTermiosImpl$Port.fail(JTermiosImpl.java:94)
at jtermios.windows.JTermiosImpl$Port.open(JTermiosImpl.java:147)
... 5 more
FAILED
Got an identifier for non-exisiting path
Test failure

Ok, thanks for reporting this. I'll have a look in the evening.

Just released 0.0.26 that should fix this issue. Please test and report back so we can close this (or continue debugging).

It still didn't work.
It looks to me that there should be a try-catch in CommPortIdentifier.getPortIdentifier ?
PureJavaComm Test Suite
Using port: COM1
TestMissingPort
jtermios.windows.JTermiosImpl$Fail
at jtermios.windows.JTermiosImpl$Port.open(JTermiosImpl.java:144)
at jtermios.windows.JTermiosImpl.open(JTermiosImpl.java:353)
at jtermios.JTermios.open(JTermios.java:419)
at purejavacomm.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.
java:101)
at purejavacomm.testsuite.TestFreeFormPortIdentifiers.testMissingPortInC
ommPortIdentifier(TestFreeFormPortIdentifiers.java:25)
at purejavacomm.testsuite.TestSuite.main(TestSuite.java:43)
Caused by: java.lang.RuntimeException: GetLastError() returned 0 getLastError=2
at jtermios.windows.JTermiosImpl$Port.fail(JTermiosImpl.java:94)
at jtermios.windows.JTermiosImpl$Port.open(JTermiosImpl.java:147)
... 5 more
FAILED
Got an identifier for non-exisiting path
Test failure

This is due to accommodating the Windows test suite use of WinAPI.  I will update JTermiosImpl to not encapsulate the OpenFile function in a try/catch bracket.  WinAPI was supposed to be only used by JTermiosImpl but the Windows test suite breaks that base rule.

The reason for the change in how we handle Windows functions using the JNA-recommended route of LastErrorException instead of getLastError is because of another issue we ran into where getLastError was being set to 0 for no apparent reason where LastErrorException would not be.  Unfortunately, this was done solely focused on JTermiosImpl which and not the Windows test suite which makes direct WinAPI calls.  I will change the code for CreateFile in JTermioImpl but if the Windows test app fails on anything else, I am going to recommend it be either removed or updated to use LastErrorException since this is the only test app that access WinAPI directly and the focus should be on the PureJavaComm interface.

I've reverted my local windows.JTermiosImpl to the original (before Direct Mapping) state and then retrofitted it to use the DM WinAPI and the new FDSet plus incorporated the original fix for the WaitCommEvent()==false GetLastError()==0 so that the LastErrorException is not used anywhere and now it passes all tests.
I did this because this morning when I finally fixed OP's error I run into next one and then another one and eventually it worked but I still got stack trace on the (err stream) console when some LastErrorExceptions were thrown (for cases that were really not errors but normal non zero return values) and I could not find how to disable those.
Also all these problems we have had with the introduction of LastErrorException convinced me that it was an error to introduce it to a code base that was coded with GetLastError in mind. Number of bugs for marginal gain and who know what corner case lurk in there.
Now I have a code that is very close the original design (implying high probability that it works for all cases that the original code worked for) and which that the DirectMapping and improved FDSet and which passes all tests.

I wish you hadn't done that because you will introduce more problems than help.  The primary issue is the Windows test suite code which shouldn't be there anyway as that is not the focus of PureJavaComm.  I made and pushed the change to JTermiosImpl already and that works without issue.  We don't know where else problems that were seen with WaitCommEvent might also occur where you were circumventing JNA's use of GetLastError.  I guarantee (after looking at the JNA native code) that if you try calling GetLastError directly, it will be replaced by their Native.getLastError() (per JNA's response) and we don't know at this point what is in the code that could be resetting Native.getLastError() to zero at WaitCommEvent.  The code that I did for LastErrorException is working for all JTermios/PureJavaComm tests and that is where our focus should be.  I have generated a pull request which brings JTermiosImpl CreateFile back to original but let's leave the rest alone as it is working correctly.  If there are other issues with the Windows test suite, it should be looked at changing from now on instead of the base code.

I'm surprised that you did not run into the test suite issues that I ran into. I implemented the same fix you just pushed and still had problems with Test9 and Test11.
As to circumventing GetLastError, that was not intentional and harmless and I've retained that change in my code.
The only real issue we have seen is with WaitCommEvent and in retrospect I think introduction of LastErrorException was too risky and sweeping way to handle an anomaly that we were able to handle with just a single if-clause. I find it hard to believe that Native.getLastError is broken (or if it is, then that should be fixed), surely this project cannot be the only/first one to run into this problem.
Something mysterious going on there for sure but no reason to expect that anything else is broken,
I'm much more concerned about the broken control flow and the general ugliness of retrofitting the LastErrorException. I should have rejected that in the first place.
I'm not worried about the Windows test suite.
At the moment I'm not prepared to allow the LastErrorException into my code base,
but I will take a time out and return to this in the evening.
(BTW I think we forget to cross check both your and the OPs JNA versions, mine is 4.0.0)

I did not run the test suite as it was unnecessary for my installation.  I use PureJavaComm because it emulates the original javax.comm interface and that is where my focus is.  As I recognized the Windows test suite was making direct calls to WinAPI, I felt it was not necessary to use since the stated purpose of PureJavaComm's JTermios implementations was to implement, without error, those functions, not necessarily directly test various system implementations directly.  I would guess the Windows test suite will fail and continue to fail with the LastErrorException adds but this is the only way we know for sure that the proper error will be passed out of the JNA code.  I am using the current JNA release 4.1.0 because that is what users will download.  If the 4.0.0 getLastError() handling was different (like supporting the persistLastError()), then that would definitely show why some of the issues were seen and makes using LastErrorException even more important since that always has persisted the error code in the exception itself.  JNA has been pushing the LastErrorException direction for quite some time now, I would guess, because of the various implementation limitations and variances and whether the last error was persisted or not.  I am guessing they are trying to remove ambiguity as well as bringing it more in line with Java coding "standards".  Personally, I am not partial either way other than wanting to be sure PureJavaComm works today and going into the future with JNA.

I had the same result with JNA 3.5.1 and 4.0.0 jars (the two that come shipped under lib dir).
And if it's of any help, I'm using Java version 1.8.0_60-b27 (64-bit).

Just to make sure we are on the same page.
I did NOT talk about and did not run and don't care about jtermios.windows.testsuite.TestSuite.
I DID talked about and did run the purejavacomm.testsuite.TestSuite.
I'm ready scrap jtermios.windows.testsuite.TestSuite and make the WinAPI visibility 'package'
(default) in effect making it private.
But I'm not ready to use LastErrorException yet.
I will consult the JNA list for about the getLastError / LastErrorException usage.

But the purejavacomm.testsuite calls the Windows testsuite so that is where the disconnect is.  If you revert back, simply change back the try/catch brackets to be tests (since those tests are already there).  Add the following line to the beginning of -every- jTermiosImpl static initializer (good that they got moved to a static initializer so we can control sequence):
Native.setPreserveLastError(true);
This ensures Native.getLastError() in -all- platforms and -all- versions of JNA does actually preserve the last error for direct mapping.  In the older JNA versions, this is the description of setPreserveLastError (from 3.5.1  JavaDoc, 4.0 says it is always true as does 4.1):
Deprecated. The preferred method of obtaining the last error result is to declare your mapped method to throw LastErrorException instead.
Set whether the system last error result is captured after every native invocation. Defaults to true (false for direct-mapped calls).

Leave fail() the way it is and and call it with new LastErrorException(Native.getLastError()).  That way you get a full stack list instead of just a line number.

Where did you get:
Set whether the system last error result is captured after every native invocation. Defaults to true (false for direct-mapped calls).
Deprecated. Last error is always preserved
This method is obsolete. The last error value is always preserved.
NOTE: The preferred method of obtaining the last error result is to declare your mapped method to throw LastErrorException.
Your quote indicates that indeed the original problem was introduced by the Direct Mapping because the setPreserverLastError defaults to false for direct mapping but what I read is that it is always preserved and thus this obsolete method is not needed and it should be safe to use getLastError.

As stated "(from 3.5.1 JavaDoc, 4.0 says it is always true as does 4.1)".  The problem with that, however, is that the problem was reported with JNA 4.0 which says that it is always true just like 4.1.  I will say that I saw issues with 4.1 when I first started testing (as I described in that issue) yet the JNA native code doesn't even look at at that setting anymore nor does the Java code so that is why we went the route of LastErrorException: that setting is ignored in JNA 4+ yet we were still seeing the issue in 4 and 4.1.  However, it doesn't hurt to have it there and might help with people using older versions of JNA.

But the purejavacomm.testsuite calls the Windows testsuite

I don't see that.

However, it doesn't hurt to have it there and might help with people using older versions of JNA.

Yes, sure, I will include that.

You are correct but a FailException should have been thrown anyway in the original code (for some reason, I thought we were looking at the Windows test suite) because fail() is being called in the original code.  So I guess I do not understand why it was failing.  If there is an issue with the FailException not being thrown correctly with the new code, then maybe we should have looked there first instead of throwing out the LastErrorException code.

@nyholku BTW, one of the things I am suspicious of is JNA's attempt to use a ThreadLocal variable in native code.  I will look at their Java code to see how they are actually allocating and accessing it.

@nyholku Maybe the issue isn't with the LastErrorException but with my implementation of the fail() method?  I would take a look at that before you start pulling all of the LastErrorException code.  As I say, we saw the reset-to-zero issue with 4.0 and 4.1 and the only sure way of getting the true last error code is using the exception.  Apparently they have a thread-local issue even though they say they don't.

@nyholku And if this is happening with Windows, could it be happening with the 'ix implementations too?  Hmmm, I don't see why it couldn't happen since they all use the same call/check error code. While this issue is in JNA, we have to deal with it properly to make sure we cover old and new JNA implementations...

@PeteSL sorry about the radio silence,just got home and I need a time out, I'll be back tomorrow.

@nyholku I fully understand.  Get some rest.  I think I understand why the problem with the test suite and it stems to the exceptions that the Fail exception gets translated to.  I guess we were doing things right with the LastErrorException but the code that translates the Fail exception to the PureJavaComm exception (like NoSuchPortException) wasn't accommodated.  I would much rather see us migrate to using the LastErrorException throughout since we have a known JNA flaw, transient as it might be, and modify the Fail exception "translation" code to generate the correct exception based on the new Fail exception format.  Just food for thought.  Get some sleep.

@nyholku To be honest, I don't see how this ever succeeded.  I am looking at the original code (before I ever touched it) and the Windows JTermiosImpl.open() always threw a Fail exception which should have failed the test:
						m_Comm = CreateFileW(new WString(filename), GENERIC_READ | GENERIC_WRITE, 0, null, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, null);

						if (INVALID_HANDLE_VALUE == m_Comm) {
							if (GetLastError() == ERROR_FILE_NOT_FOUND)
								m_ErrNo = ENOENT;
							else
								m_ErrNo = EBUSY;
							fail();
						}

Please tell me how this ever passed the test.  I am not being argumentative.  I am trying to understand.

All of this and I found the issue was in my initial wrap of the CreateFile function in the port.open() method.  If you apply my pull request, there will no longer be any issue.  This really had nothing to do with catching the LastErrorException and I believe we should continue to use it throughout the code, not just in the Windows implementation because of the issue we found with how JNA might be resetting the getLastError value (we don't know where it might surface elsewhere).  This is why the original wrap was wrong (from the commit #58 history listing):

-						m_Comm = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, 0, null, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, null);
+                                                try {
+                                                    m_Comm = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, 0, null, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, null);

-						if (INVALID_HANDLE_VALUE == m_Comm) {
-							if (GetLastError() == ERROR_FILE_NOT_FOUND)
-								m_ErrNo = ENOENT;
-							else
-								m_ErrNo = EBUSY;
-							fail();
-						}
+                                                    if (INVALID_HANDLE_VALUE == m_Comm) {
+                                                        m_ErrNo = EBUSY;
+							throw new LastErrorException(0);
+                                                    }
+                                                } catch (LastErrorException lee) {
+                                                    fail(lee);
+                                                }

Should have been:
+                                                } catch (LastErrorException lee) {
+                            if (lee.getErrorCode() == ERROR_FILE_NOT_FOUND)
+                               m_ErrNo = ENOENT;
+                           else
+                                m_ErrNo = EBUSY;
+                                                    fail(lee);
+                                                }

All of this because I didn't translate that portion of the code correctly.  Sorry for the confusion.  The last pull request will work with the CreateFile that doesn't throw a LastErrorException.  If you want to re-implement the LastErrorException, I can make this change as well which will ensure we get the actual GetLastError() code.

Good Pete, the code snippet is really exactly what makes it work. I don't see how I can put that more clearly. If the comm port fails to open we fail. m_ErrNo is set to reflect the reason for the failure as reported by the GetLastError. Either the port is not there of it is in use (we don't handle access rights separately as JavaComm does not handle that either. The void open(String, int) who calls this function captures the failure and returns -1 and the 'client' code then checks the JTermios.errno() in the usual *nix manner.
Because your mod did not set the errno correct the original test failed as the PureJavaSerial.open got the impressions from the (EBUSY) that there port exists but is busy.
(BTW thisvoid open(String, int) should actually be private as it only exists to make  the int open(String,int) more clear or they could be merged.

@PeteSL  I see my comments were behind times. No matter.
I've been mulling over this for a good deal and I'm not going to allow LastErrorException in my code base.
I've not pulled your latest and thus don't know how well it behaves but what drove me over the edge was yesterday when I had fixed above issues I run into this:
Test11 - exit from blocking read/write        .com.sun.jna.LastErrorException: [996] Overlapped I/O event is not in a signaled state.
at jtermios.windows.WinAPI$Windows_kernel32_lib_Direct.GetOverlappedResult(Native Method)
at jtermios.windows.WinAPI.GetOverlappedResult(WinAPI.java:779)
at jtermios.windows.JTermiosImpl.write(JTermiosImpl.java:520)
at jtermios.JTermios.write(JTermios.java:433)
at purejavacomm.PureJavaSerialPort$1.write(PureJavaSerialPort.java:636)
at purejavacomm.testsuite.Test11$2.run(Test11.java:94)
at java.lang.Thread.run(Unknown Source)
At that point in time I did not want to dig any deeper and took this as evidence of more logic broken because of the LastErrorException breaking the control flow.
In summary I wont use LastErrorException because:

introducing it this late in the project demonstrably risks a series of new bugs
introducing it this late throws away a lot of the confidence built by years of usage (because of the sweeping nature of the change)
In Windows many error codes are not errors but normal flow so throwing exception is conceptually and aesthetically wrong plus it adds small but unnecessary overhead
there is no evidence that the anomaly we saw is widely spread (I've not seen that anomaly myself at all)

I'm sorry you have put so much time into this LastErrorException, I should have refused this in the first place.
You've done sterling work everywhere but I just can't see my way to allowing LastErrorException here.
I guess we need to agree to disagree on this one.

@nyholku I understand your frustration (I was not complete in my implementation of the try/catches) but also understand that the getLastError could be reset to zero in any instance.  This was not unique to the WaitCommEvent call since it is working correctly.  Something in JNA where this error code is supposedly kept in a thread-local variable is resetting it to zero and the LastErrorException is the only sure way of getting the real code generated.
Interesting on the error because that is something I made sure was handled correctly.
                                try {
        				if (!WriteFile(port.m_Comm, port.m_WrBuffer, length, port.m_WrN, port.m_WrOVL))
                                            // Should never get here so tell us
                                            throw new LastErrorException(0);
                                } catch (LastErrorException lee) {
                                    if (lee.getErrorCode() == 0)
                                        System.err.println("ReadFile returned false but GetLastError==0");
                                    else if (lee.getErrorCode() != ERROR_IO_PENDING)
                                        port.fail(lee);
                                    port.m_WritePending = length;
                                }

so the port.m_WritePending only gets set if there is a write pending and is reset to zero if the overlapped operation completes (I did not change that portion of the code at all). (I know, copy/paste got me with the note about "ReadFile returned false but GetLastError==0" but that is just cosmetic.)
As I say, I am not tied to LastErrorException and if you want to revert back, please do so with the understanding that we have identified an issue in JNA where the Native.getLastError() function may not return the actual value that was returned immediately after the Windows function call and that the static initializers need to have the Native.setPreserverLastError(true); line in all JTermiosImpl to ensure compatibility with pre-4.0 JNA code.  Also, since we identified the JNA issue with WaitCommEvent, be sure to consider GetLastError() to be ok if it is zero at that point.  You may want to return to this in the future if direct mapping, which is significantly faster on all platforms, if JNA continues to present last error issues in your code.  I will continue to support your excellent efforts with this product.

@nyholku I also note that you do not check which event triggered the WaitMultipleObjects in that part of the code.  Could it be that the port got closed before the operation completed?  That would cause the WaitMulipleObjects to fire but not have an Overlapped result.  Just thinking out loud again...  Keep in mind that with direct mapping, things happen a lot faster and race conditions are going to be more visible.

@nyholku Your test didn't fail!  It simply reported that the write operation did not complete!  I add printStackTrace code to read, write, and open so we could see the actual error being generated!  Again, the test didn't fail as it returned -1 without error but at least we now know what caused it!

@nyholku I understand your frustration but you made an invalid assumption that the write code was broken; it is not.  If you don't want to see the stack traces on errors, remove them but don't assume the lasterrorexception handling is broken if the tests are not failing, just reporting what the underlying error was.  Do as you will but I still believe the only way you will ensure proper operation of the direct mapping code is with LastErrorException because of the known JNA implementation issue we have identified.

Do as you will but I still believe the only way you will ensure proper operation of the direct mapping code is with LastErrorException because of the known JNA implementation issue we have identified.

This is what the JNA author T Wall had to say about this:

There have been a few reports of uncertainty around GetLastError, but no one's produced anything concrete and not attributable to w32 API inconsistency.

Yes, and we were able to produce a concrete example on 1 computer in one environment and duplicate it in another environment but no longer reproducible on that environment.  The code I put in for the LastErrorException is also reporting anytime an error occurred and getLastError is reset to zero or, in the case of WaitCommEvent, where an error was expected but did not occur.  That way we could definitively track this phenomena and see if it was JNA resetting the Java variable or GetLastError() actually being reset in the native code.  In the long run, we could be doing the JNA folks a favor by leaving the LastErrorException code in there as it will tell us if GetLastError() is returning 0 when it shouldn't be (but we are considering it bad anymore so PureJavaComm won't break).

@nyholku I see you reverted away from every looking for LastErrorException and I believe that was extreme the other direction for my 2 coding errors.  This is not something directly tied to the WaitCommEvent but tied to why GetLastError() is being set to zero (success) after the WaitCommEvent returns.  If this is tied to concurrent operations using direct mapping, then we might see it again with ReadFile, WriteFile, and GetOverlappedIO (would be my guess).  WaitMultipleObjects is still in the regular JNA mapping class so that will likely not have the issue (we saw this with the implementation of direct mapping which may just be a coincidence but...).  I would recommend we revisit the throw LastErrorException for those functions (and WaitCommEvent) and simply move the return false error handling to the catch part of the try/catch where those functions are called.  This will minimize the likelihood of coding errors (which I acknowledge that my coding errors were the sole source of problems with the prior implementation) and ensure we get the true code returned by GetLastError().
I didn't see the add of Native.setPreserveLastError(true); to the static initializers (but I admit I didn't look too closely yet).  I would do that just to ensure pre-4.0 JNA users will properly work with the Direct Mapping implementations.

On 12 Sep 2015, at 19:07, PeteSL<EMAIL_ADDRESS>wrote:
@nyholku I see you reverted away from every looking for LastErrorException and I believe that was extreme the other direction for my 2 coding errors. This is not something directly tied to the WaitCommEvent but tied to why GetLastError() is being set to zero (success) after the WaitCommEvent returns. If this is tied to concurrent operations using direct mapping, then we might see it again with ReadFile, WriteFile, and GetOverlappedIO (would be my guess). WaitMultipleObjects is still in the regular JNA mapping class so that will likely not have the issue (we saw this with the implementation of direct mapping which may just be a coincidence but...). I would recommend we revisit the throw LastErrorException for those functions (and WaitCommEvent) and simply move the return false error handling to the catch part of the try/catch where those functions are called. This will minimize the likelihood of coding errors (which I acknowledge that my coding errors were the sole source of problems with the prior implementation) and ensure we get the true code returned by GetLastError().

I prefer to wait and see if we get problems, if we do I'll eat the humble pie and admit I made a wrong decision.

I didn't see the add of Native.setPreserveLastError(true); to the static initializers (but I admit I didn't look too closely yet). I would do that just to ensure pre-4.0 JNA users will properly work with the Direct Mapping implementations.

My bad, I had done all this before that subject came up and forget as I've rather busy past two days. I will add that to next release (hopefully within days).

@nyholku I understand.  BTW, I think I have identified why Native.getLastError() is being reset to zero: it is NOT thread local storage, it is in -process- local storage.  The JNA code was originally written for 'ix platforms which supports something called pthread functions.  However, when you load a DLL in Windows, it is loaded by the process:
BOOL WINAPI DllMain(HINSTANCE hDLL, DWORD fdwReason, LPVOID lpvReserved) {
  switch (fdwReason) {
  case DLL_PROCESS_ATTACH:
    tls_thread_data_key = TlsAlloc();
    if (tls_thread_data_key == TLS_OUT_OF_INDEXES) {
      return FALSE;
    }
    break;
  case DLL_PROCESS_DETACH:
    TlsFree(tls_thread_data_key);
    break;
  case DLL_THREAD_ATTACH:
    break;
  case DLL_THREAD_DETACH: {
    thread_storage* tls = (thread_storage*)TlsGetValue(tls_thread_data_key);
    if (tls) {
      dispose_thread_data(tls);
    }
    break;
  }
  default:
    break;
  }
  return TRUE;
}

Note they are creating "thread local storage, TLS" for the -process- attach, not the thread attach because they are using a static variable in callback.c for tls_thread_data_key, not a thread-local variable.  Bottom line is if they wanted -Java- thread-local variables, they should have accessed ThreadLocal variables in Java, not -assume- that every JVM creates a separate native thread for each thread (they don't) and then they should have realized they aren't creating a thread-local variable for Windows, it is a process-local variable.
That explains why it was rare and why throw LastErrorException always works (that code is on the stack, always thread-local) and Native.getLastError() can fail on Windows (I don't know enough about pthreads and 'ix dynamic library calls to guess whether it might be an issue with them).  The reason we hadn't seen it before (or didn't realize it) is because Direct Mapping is so much faster that the likelihood of getLastError() being set to something new in a different thread is significantly higher than with JNA mapping.
I know you are tired of the LastErrorException issue but it was bothering the heck out of me as to why LastErrorException would never fail (be set to something else) but Native.getLastError() could fail.  We now know the answer and why the only reliable catch of Windows GetLastError() is with the LastErrorException.

@nyholku I will be happy to revisit using throw LastErrorException and -this- time simply use try/catches to wrap each function in WinAPI.  Also, to make it as transparent as possible, I will use a ThreadLocal variable for last error in WinAPI so there won't need to be any code changes outside of WinAPI!  Does that sound like a reasonable compromise?

On 12 Sep 2015, at 20:58, PeteSL<EMAIL_ADDRESS>wrote:
@nyholku I understand. BTW, I think I have identified why Native.getLastError() is being reset to zero: it is NOT thread local storage, it is in -process- local storage. The JNA code was originally written for 'ix platforms which supports something called pthread functions. However, when you load a DLL in Windows, it is loaded by the process:
BOOL WINAPI DllMain(HINSTANCE hDLL, DWORD fdwReason, LPVOID lpvReserved) {
switch (fdwReason) {
case DLL_PROCESS_ATTACH:
tls_thread_data_key = TlsAlloc();
if (tls_thread_data_key == TLS_OUT_OF_INDEXES) {
return FALSE;
}
break;
case DLL_PROCESS_DETACH:
TlsFree(tls_thread_data_key);
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH: {
thread_storage* tls = (thread_storage*)TlsGetValue(tls_thread_data_key);
if (tls) {
dispose_thread_data(tls);
}
break;
}
default:
break;
}
return TRUE;
}
Note they are creating "thread local storage, TLS" for the -process- attach, not the thread attach because they are using a static variable in callback.c for tls_thread_data_key, not a thread-local variable. Bottom line is if they wanted -Java- thread-local variables, they should have accessed ThreadLocal variables in Java, not -assume- that every JVM creates a separate native thread for each thread (they don't) and then they should have realized they aren't creating a thread-local variable for Windows, it is a process-local variable.

I think you should rehash this in the JNA list both to check the validity
of your conclusion and alert them of this issue so they can fix it.

@nyholku I will but I also think the modification to WinAPI would be effective and would be guaranteed to work now with PureJavaComm without rewriting anything other than the WinAPI methods and would work with any JNA version, even if JNA fixes this in the future.

On 12 Sep 2015, at 21:03, PeteSL<EMAIL_ADDRESS>wrote:
@nyholku I will be happy to revisit using throw LastErrorException and -this- time simply use try/catches to wrap each function in WinAPI. Also, to make it as transparent as possible, I will use a ThreadLocal variable for last error in WinAPI so there won't need to be any code changes outside of WinAPI! Does that sound like a reasonable compromise?
—
Reply to this email directly or view it on GitHub.

Can you give me an example how you would go about it?
In the static method you wrap the call to the native
function in a try/catch LastErrorException, capture the
last error from the exception and keep it in a thread
local variable; and the modify the GetLastError to get
the error code from there?

@nyholku Exactly.  And if the exception is thrown, the static method will return false, just like it is supposed to.

@nyholku That is a quick and painless fix that will work today and tomorrow with any JNA version.

@PeteSL I can live with that! This approach seems very safe, so go ahead, I'll merge it.
But also consider letting the JNA people know about the bug ... or you mind if I do?

@nyholku Since you already have this issue open with them, feel free to take it to them.  I think it could be an issue with 'ix platforms as well if the JVM doesn't do native threads for each Java thread but that is just conjecture on my part.  It is definitely an issue with Windows as we have seen.  I will rebase to 0.0.27, make the mods and also add the Native.setPreserverLocalError(true); lines to the static initializers (harmless as well and will help people using pre-4.0 JNA).

@st-arnold Please test version 0.0.28 which has PeteSL's latest changes merged and report back.

hi all, I hope you'll excuse my interjection, I'd like to tackle this closer to its source.
On w32, JNA establishes a thread-local index on process attach.  The actual thread-local storage is lazily created by any subsequent thread actually asking for access to it.
The JVM generally does do a native thread per JVM thread, and creates JVM Thread objects when a purely native thread does an "attach" operation.  Even if the JVM were managing its own multi-thread execution within a single native thread, that type of multi-tasking would not be capable of pre-empting in the middle of native code outside its control.
It'd be great if I could reproduce this in (relative) isolation, if for no other reason than to be able to verify if/when the issue is fixed.

Please note that any direct-mapped calls to GetLastError() should be replaced by Native.getLastError().  Where JNA could intercept such calls with interface mapping, it does not do so with direct mapping.  Calling the API method directly will not necessarily provide you with the error set on the last API call, while Native.getLastError() will.

I appreciate your endeavor to analyze the JNA win32 code but contrary to your analysis, it does not create TLS storage on a thread basis; it is allocated on a process basis (unfortunately).  We do not use a native mapped GetLastError() nor have we used a direct call to GetLastError() since initial implementation of the direct mapping.  We were able to prove the Native.getLastError() value was being overwritten in certain Windows environments at the WaitCommError call in the select() code.  Key word here is "certain" because this is a timing issue where another thread overwrites the Native.getLastError() value before it is checked in this thread (this issue was proven and is semi-acknowledged by the JNA group, "rumors but no concrete examples").  We have also proven that using LastErrorException where the last error code is saved on the stack and then put directly into the exception (undeniably thread-local) ensures the code is not altered.
This puts us back to release 0.0.28 uses LastErrorException exclusively for the WinAPI code, uses a definitively Java ThreadLocal value to hold the last error code for calls to WinAPI.GetLastError() (not Windows GetLastError() or Native.getLastError()) which works in all cases with all recent versions of JNA (at least from 3.5.1 on).

The TLS index is created on a per-process basis (via TlsAlloc).  This establishes an identifier that may be used across all threads to modify the contents of a thread-specific "slot"[1].
The actual reference to storage (maintained via TlsGetValue() and TlsSetValue() using the per-process TLS index) is definitely created and destroyed on a per (native) thread basis.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686991(v=vs.85).aspx

Tim, I am going to ask you to pursue this on the JNA Github group.  As I stated, we have proven that Native.getLastError() could be overwritten by another thread (or something else in JNA) and that 0.0.28 uses the LastErrorException and stores the thrown error code (passed on the stack to the point the exception is thrown so it -can't- be overwritten) in a Java ThreadLocal variable.  This is known to never overwrite the variable from another thread and PureJavaComm works correctly.
I have been writing Windows serial communications software for over 2 decades and am very aware of how all of the Windows APIs work.  I do not need references to MSDN library pages (I am a MSDN author for a many decades).  I understand your desire to defend the JNA code but we have proven the case where the "native thread local" storage is apparently being overwritten and we also have a proven method to avoid such issues in all JVMs and native implementations.
By the way, you said that if the JVM is internalizing the threads, it can't interrupt the process.  True, it won't interrupt the native process but there is certainly nothing that prevents it from interrupting the Java method between lines.  Again, not trying to pursue this any further here since we have a working solution.  Any further pursuit of this should be done with the JNA group.

Pete,
I appreciate your feedback here.  What I'm trying to obtain is a set of concrete steps that have some likelihood of reproducing the problem you've seen.  Maybe @nyholku can help me out, but I'm not familiar with the situation and/or code that has been triggering the problem, and I'd be hard pressed to reproduce it from scratch.

@PeteSL perhaps with your extensive experience with all of the Windows APIs you could point out the flaw in JNA's usage of TLS as I've described it?

@twall This is not the place to delve further into the underlying JNA architecture.
I am not being argumentative.  I have told you that this was concretely identified and it was resolved in a prior issue with PureJavaComm (please review recent issues that were resolved).  I was always bothered by the statement "it is thread-local so it can't be overwritten" when we had someone definitively identify it being overwritten and implementing the LastErrorException code resolved this issue.  As I have also said, you are not going to take steps X, Y, and Z to recreate it because it is a -timing- issue and may also be an issue with specific JVMs and JNA implementations.
The expectation by JNA that each Java thread = a native thread is an invalid assumption and I believe they are leaving themselves open for future issues with other projects.  This project, however, is working because we are not depending on JNA's native thread-local storage, at least in the Windows implementation.  Quite honestly, I don't have the time to pursue this with JNA right now and I don't think the PureJavaComm group is the place to pursue it either.

@twall Sorry I can't help you with a test case as this never happened to me.
The evidence for the problem, such as it is, is here:
https://github.com/nyholku/purejavacomm/issues/57
For me this is not 100% conclusive but I wanted to err on the safe side so we applied the try/catch fix as it looked safe enough.
My take on the situation:
We have two cases where this happened, the original issue reporter's and Pete's own experience (though in hindsight that is not very clear from the thread but I have presumed he saw this himself).
It is difficult to see how PJC bug could cause a problem like this
It is equally difficult to see what the problem on the JNA side is, if any.
A Windows anomaly WaitCommEvent reporting false with GetLastError reporting 0 would be a nice way to push this into Microsofts corner;)
That is also hard to believe, though it could be as maybe the proper way to code with GetLastError is to check that it is equal to some value whereas in PJC code I check (effectively via else) not-equal to the expected value and report that as a failure. This would explain why no-one else has seen (or publicly reported) this problem with Win serial API.

@nyholku Sorry this issue got off track.  Hopefully we will get closure soon on it.
It may be that the native code is just fine but... their assumption that native thread = Java thread is an invalid assumption, especially with fork/join thread pools introduced in more recent JVMs.  Also, many JVMs manage native threads internally for various reasons (there was a lot of problems in early JVMs on various operating systems using up thread handles in larger Java applications, for instance).  That may be what we were seeing, as well and, to be honest, what I am leaning towards as the root cause at this point: the JVM reusing a native thread for multiple Java threads.
In any case, going to the LastErrorException puts us in the right place guaranteeing a Java thread-safe GetLastError(). One cleanup you may want to consider (and I will be happy to add if you want it) is to not call FormatMessage in fail() anymore but take the message from the LastErrorException message.  Easy enough to change the ThreadLocal<int[]> to a ThreadLocal where errorstruct would be an int code; and String msg;.  Not necessary as your code is working correctly but something that would clean it up just a bit going into the future.  We could call FormatMessage once during initialization to preload the message for 0 so that wouldn't have to be called every time.  This is definitely not something to do until we have verified everything is working correctly but something to keep in the back of your mind for a future cleanup.
Thanks again for your great work.  We identified a bug in JNA (may be just the assumption that native = Java regarding threads) but also a very effective workaround made much easier by your placing the Windows API calls in their own class and encapsulating them.  That was a very simple change from a native thread-safe GetLastError() to a Java thread-safe GetLastError() because of that isolation you did early on.

@twall Tim, one thing to consider (and this may very well have been the case) is that a Java thread does not have to equal a native thread.  In the early Linux JVMs from Sun, for instance, using native threads was experimental because of some thread handle issues.  In current JVMs, there are Fork/Join pools which an author can forcibly share Java threads.  And no place in JVM architecture requirements is there a mandate that native=Java for threading.  In fact, the exact opposite has always been in place (the JVM implementation is independent of the underlying OS and can manage threading independently of the OS).  I know you think the current Oracle JVM for Windows is a one to one correspondence, but maybe not.  And the JNA folks can't assume every JVM will be a one to one thread match.
I go back to my original statement in issue #57 that something is overwriting the "thread-local" variable which tells me it is not Java thread local.  I fully believe that to ensure platform independence (a JNA stated intent), the native code needs to be using a Java ThreadLocal variable or passing out a structure on the stack that contains any variables that need to be thread-local to the Java threads.  Java ThreadLocal variables are relatively high overhead but are the only things guaranteed to be Java thread-local.
We have our workaround for PureJavaComm that is probably the way it should have been implemented in the first place, had he realized the Native.getLastError() was not guaranteed to be Java thread-safe (again, may be native thread-safe but that doesn't make it Java thread-safe) so this issue will end up being closed for PureJavaComm.
If you want to take this thought process over to the JNA group, please feel free to.  Remember, nowhere in the JVM architectural specs does it say a Java thread = a native thread and, in fact, the JVM architects continue to move more and more to JVMs managing their own threads.  These are all things to keep in mind if you take this back to the JNA folks and these caveats apply to all OS platforms, not just Windows.

On Sep 14, 2015, at 6:28 AM, PeteSL<EMAIL_ADDRESS>wrote:
@twall Tim, one thing to consider (and this may very well have been the case) is that a Java thread does not have to equal a native thread. In the early Linux JVMs from Sun, for instance, using native threads was experimental because of some thread handle issues. In current JVMs, there are Fork/Join pools which an author can forcibly share Java threads. And no place in JVM architecture requirements is there a mandate that native=Java for threading. In fact, the exact opposite has always been in place (the JVM implementation is independent of the underlying OS and can manage threading independently of the OS). I know you think the current Oracle JVM for Windows is a one to one correspondence, but maybe not. And the JNA folks can't assume every JVM will be a one to one thread match.

I’m quite willing to entertain the notion that Java thread != native thread.  A couple of points, though:

green threads were abandoned quite some time ago, circa Java 1.3
I’ve not seen any recent JVM development around resurrecting them.  You suggest that you have, so I would be grateful if you could point me to this interesting JVM architecture activity; I’ve not been able to find anything, but perhaps I’m not looking in the right places.
the case(s) where you found the issue were not running an exotic, bleeding edge VM, so there should be some evidence that the Oracle JVM for Windows (assuming that’s what you were using), exhibits this behavior, if nowhere else but in the source.

What is quite common, though, is folks using an explicit call to GetLastError() instead of Native.getLastError(), or inadvertently making additional native calls before retrieving the last error result.
I’m trying to think what might be useful to expose more information, without introducing undue overhead on the native side.   Is there some check that could be made (comparing JNIEnv*, perhaps) to identify that the native TLS is effectively being written by a different Java Thread than a previous write?  Certainly calling Thread.currentThread() is doable, but would have a significant execution impact which might end up affecting results.

I go back to my original statement in issue #57 that something is overwriting the "thread-local" variable which tells me it is not Java thread local. I fully believe that to ensure platform independence (a JNA stated intent), the native code needs to be using a Java ThreadLocal variable or passing out a structure on the stack that contains any variables that need to be thread-local to the Java threads. Java ThreadLocal variables are relatively high overhead but are the only things guaranteed to be Java thread-local.
We have our workaround for PureJavaComm that is probably the way it should have been implemented in the first place, had he realized the Native.getLastError() was not guaranteed to be Java thread-safe (again, may be native thread-safe but that doesn't make it Java thread-safe) so this issue will end up being closed for PureJavaComm.
If you want to take this thought process over to the JNA group, please feel free to. Remember, nowhere in the JVM architectural specs does it say a Java thread = a native thread and, in fact, the JVM architects continue to move more and more to JVMs managing their own threads. These are all things to keep in mind if you take this back to the JNA folks and these caveats apply to all OS platforms, not just Windows.
—
Reply to this email directly or view it on GitHub.

@twall Tim, that was sent privately to you but you chose to broadcast it.  That terminates this conversation.
Bottom line is we have it working with LastErrorException, it was not working with Native.getLastError() (so get that out of your thought process) because Native.getLastError() was getting overwritten within one Java line (yes, there were non-native log calls but no calls to JNA) and I have given you two hypothesizes which you consistently say "prove it".  I don't have to and I am done with this.  I don't care whether you figure this out in the JNA group or not at this point because your attitude is "we are right unless you can prove otherwise".  I have given you examples of where native threads might be reused (and even though "green threads" were left behind in Sun's Linux implementation, it doesn't mean and was never put into the JVM spec that a Java Thread must correspond 1 to 1 to a native thread).  If you can come up with a reason why Native.getLastError() was being overwritten when nothing in that thread was making a JNA call in between the call causing an error and the Native.getLastError() call, great!  I am done offering possibilities or discussing this further with you.

@nyholku @PeteSL
I'm happy to report that the test suite in version 0.0.28 now passes all tests when using jna-4.0.0.jar.
But when using 3.5.1, Test 9 causes Java.exe to crash ("An unhandled win32 exception occurred in java.exe").
Test9 - treshold 100, timeout 100
(not a single "dot" gets printed before the crash)
Here's my version info:
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

@st-arnold Did it produce a crash report?

@st-arnold @nyholku
Thanks!  I can almost guess what caused the crash with 3.5.1 and you can verify or deny this if you have time.  Part of the last commit for direct mapping support was to add Native.setPreserveLastError(true); to each JTermioImpl static initializer and WinAPI static initializer in the Windows implementation (right up near the top of the source code).  We don't need it in WinAPI because we are exclusively using LastErrorException in that code so can you comment out (//) that line and recompile and and rerun against the test suite?  If it runs without error, we have identified something in the pre-4.0 JNA.  If it fails in the same place, then we have identified an issue with pre-4.0 JNA and LastErrorExceptions.

@nyholku No, Windows just offers Just-In Time debugging (which I'm not competent enough to do, I'm afraid).
I tested with another computer (old 32bit WinXP with Java v1.6.0_23), using the same USB-RS232 adapter, and there it works with both 3.5.1 and 4.0.0.
So it seems to be related to Windows version, 32 vs. 64 bit or Java version.
I'll try updating Java on that old computer and then test again.

Some more info:
Looks like 1.6 is the latest Java for WinXP so I couldn't update.
I tested with another USB-RS232 cable on Win8.1 64bit Java 1.8, same problem, so it's probably not a hardware issue (although both are FTDI adapters but slighly different). I also have one PL-2303 adapter but it doesn't want to work in this computer...
@PeteSL I'll try to recompile the source, as a newbie I haven't done it before and the "compile" script seems to be made for 'ix.

Hmm... Seems to be an issue with Java 1.8 ?
I ran the test suite with JNA 3.5.1 + Java 1.7.0-71 and all tests passed.
(Didn't modify the source yet)

@st-arnold the compile script has the command line for compiling the code (it is a single line) and IIRC it works verbatim on Windows too (maybe replace the slashes with backslashes, don't remember)

@st-arnold I would recommend getting Eclipse for Windows, then you can single step code easily and see variable values etc etc.

@PeteSL Did you mean commenting out just line 101 in WinAPI.java or something else in addition?
I managed to compile (with 1.7, I had only that JDK installed, should it matter?) with that line commented out and the problem persists when run with java 1.8 and JNA 3.5.1.

@nyholku I have both Eclipse and Intellij IDEA installed. Just tried single stepping purejavacomm with the latter, seems to work. So now I'm better equipped to test and debug.
Now to learn how to make it use lib 3.5.1 ....

@st-arnold
Yes, that is exactly what I was asking (comment out 101 in WinAPI).  That is great information.  Sounds like there is some interaction with 3.5.1 and the 1.8 JVM (are you using 32 or 64 bit Java on that test?).  The reason I had you comment that line out is because in 4.0+, that is a no-operation method (literally does nothing).  In 3.5.1, it changes how they work with Native.getLastError() so I was checking to see if that was the change breaking 3.5.1.  Apparently that is not the change that breaks 3.5.1 with JVM 1.8 but at least you have confirmed this not an issue at all with 4.0 and higher JNA (I use both 32 and 64 bit JVMs to test they are Oracle 1.8 but I am solely testing with JNA 4.1).  1.8 introduced a number of new threading mechanisms so that might be where the failure is occurring.  Anyone's guess ;-)  Thanks much for your work testing this!

OK, now I can reproduce the problem while debugging in IDEA. (It took a little while to figure out how to compile with JNA 4.0.0 but run with 3.5.1.)
The crash happens at Test9.java line 90: startReadThread();
If I "step over" that statement, it crashes.
But if I step into the function and single step over statements until return, I can reach Test9.java line 95:  m_Out.write(m_TxBuffer, 0, txn);
And then it crashes.
Stepping into write function, the crash happens when entering checkState() function. I step into it and then java crashes.

Commenting out the first startReadThread() at line 84 prevents the crash.

In theory, Test 9 is really "illegal" as it is using 2 threads to read the same port.  If the port timed out (like it is supposed to) in the line 85 thread, the serial port might be left in an unknown state when the line 90 thread starts.  This is pure conjecture but there might be something in the way 1.8 handles threading which is messing with the 3.5.1 handling of native dispatch and callback where 4.0 they changed that some so it might be reset properly before the second thread starts.  This is pure -conjecture- on my part.  I don't see an issue with saying fully tested on 4.0+, may see issues with multithreading in JNA 3.5.1 and JVM 1.8 or higher.  If they are running 1.8 JVM, they should be running 4.0 or higher JNA, IMHO.

Okay, I'm not going to dig deeper as it's working fine with JNA 4.0.0.
Maybe the test should be modified, though, so it would also pass with 3.5.1?
(Or at least change run.bat to use 4.0.0 lib, because that's what newbies like me try first out of the box :)
I guess this issue can be closed now?


feature-request: Sync my extensions between to systems (Mac <--> Windows)

Hi,
I am using Mac and Windows at Work/Home. I have VS code in both.
If we have a feature to sync all extensions between both systems. That will be very good.
Something like Visual Studio theme sync.
And give the option to install button in the Web site to push extensions to all systems, the user logged in. (Like Android/WP store)
Thank you,
Naga Harish.

That'd be great.
Maybe if we could log in inside VS Code with a MS account, just like it's done in VS, keeping all the stuff synchronized.

Duplicate of https://github.com/Microsoft/vscode/issues/2743
In the meantime, this extension is the typical way of doing this https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync


Add cop: ObjectDescription

Good:
class Types::UserType < Types::BaseObject
  description "Represents application user"
end

@DmitryTsepelev Hi. I have thought about this problem and can't find an optimal solution yet.
Problem: in order to recognize that the current class is a "Type", you need to convert the name of this class to a constant and call its ancestors. Because the parent class can be the inheritor of Types:: BaseObject. But we don't have access to the constants of the application where rubocop is called.
For example:
class Types::MyClassName < GraphQL::Schema::Object
end

class Types::UserType < Types::MyClassName
end

Accordingly it is not possible to call Object.const_get(Types::UserType).
It may not be reliable to rely on the name of the namespace Type, or on the presence of "Type" in the name of the class. Any ideas?

@0legovich By default graphql-ruby generates a folder called /graphql with nested types and mutations folder (/graphql is already used here to avoid running these cops outside of the folder). I think we could start with a pretty simple solution: find out what folders are generated and add some obvious patterns that are missing (types, mutations, subscriptions, resolvers etc.) and use them, users can always extend this list


Update some logo

I updated some logo links in the m3u file, notably the BS Fuji which was not working anymore, but also others which I though looked better or were of higher quality.
If you prefer to keep some of the current ones, feel free to just take a few of them and reject the PR :)

Seem the TV Tokyo logo are down. I'll merge it and change the links.

Weird, it was working for me, it may have to do with location. The one you put is better anyway though 👍


Call out where to find the authorize all pipelines settings

I had a difficult time finding this setting. You need to click project settings, agent pools, click your pool (e.g. Default), and then click the Security tab. Perhaps include a screenshot of the setting?

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

ID: ee4ec9d0-e0d5-4fb4-7c3e-b84abfa290c2
Version Independent ID: 3e2b80d9-30e5-0c48-49f0-4fcdfedf5eee
Content: Resources - Azure Pipelines
Content Source: docs/pipelines/process/resources.md
Product: devops
Technology: devops-cicd
GitHub Login: @vtbassmatt
Microsoft Alias: macoope

We've started to avoid screenshots in the docs because they rapidly get out of date. Resource auth is also being heavily worked on right now, so I expect this to be easier going forward.


eosio.msig can undo account transfers.

Problem
There are currently two competing EOS account exchanges live:
https://www.eosnameswaps.com
https://eoscontract.io/exchangename
As documented here,https://medium.com/@motchamotcha/eosio-multisig-contract-vulnerability-b5289d18223f, both dApps are vunerable to unexecuted eosio.msig proposal/approvals that restore an accounts permission after it has been transferred to a new user.
It is currently possible to check the eosio.msig tables for proposal/approvals by the account in question. It is not possible to check whether a proposal that affects the permission of an account has been proposed by a different account. There is therefore no guaranteed in-contract method for transferring accounts. Other applications, such as account lending and ram shorting, can also not be developed.
Possible Solution
Modify eosio.msig to emplace the account name that is being affected by an msig action into a table that can be searched.
Note: There is similar vunerability with deferred transactions.

A simpler solution may be to enforce a rule that msig updateauth transactions can only be proposed by the account being affected by the permission change.

Or perhaps an unapproveall action. There is currently no way to know what msig transactions are approved, but not executed, by an account. The assumption is the account owner approved these; that may or may not be the case.

@StarryJapanNight ,
from https://medium.com/@motchamotcha/eosio-multisig-contract-vulnerability-b5289d18223f

However, if user2 now executes the multisig proposal,
Is there any way to trick user2 into executing the proposal?
If no, I would say that there is no vulnerability here, since people normally don't execute random multisig proposals without reviewing them.
Right now I am not saying that there is nothing to improve here. Just want to make sure that my understanding of severity of this issue is correct.

There is similar vunerability with deferred transactions.

What do you mean?

User2 and user1 are both controlled by the same individual. By using the user2 account to execute the msig proposal, it will not be listed under user1's scope. Once the user1 account is transfered to a new owner (say user3), there is no way they would know about the proposals made by user2. Yet they have the ability to change user1's permissions at any time.
Deferred actions can be used to set a permissions change that doesn't execute for months later. Again, only by searching blocks can a new owner know this exists.
There needs to be in-contract methods for detecting live msig/deferred transactions.

Can we make a decision on whether this needs attention or not?

Although selling accounts was not a feature that we originally intended to support, we are planing a fix in multisig contract for this issue.

@StarryJapanNight
Now multisig contract supports action "invalidate" which invalidates all previous approvals. So, you will need to call it when you transfer ownership of an account (calling it it in the same transaction is the safest).
The fix is available in develop branch. So, it should be included in the next release. Than it will be up to block producers to upgrade multisig contract on mainnet.

Excellent work. This is simple for me to implement. Two questions:

Will this invalidate all historical msig proposals related to an account? Even before the code change?

Is it possible to make a similar change for deferred actions?

Thank you for your detailed response. My current solution is once the account ownership has been transferred to the contract, to manually screen it for possible complications before allowing it to be sold. This is effectively the escrow you talk about. While this solution is most definitely not decentralized, nor programmatic, I believe it can resolve most of the potential issues with minimal burden to the developer.  Other developers may not like this solution, but for the specific case of account exchanges, I don't currently see any alternative.
I appreciate the efforts that have gone into thinking about this problem. The msig code update potentially helps resolve issues for other types of contracts, and is a valued addition in itself.


[4.1.x] URL::action generator add parameters as query strings (?a&b&c) not as short url (a/b/c)

hey,
in version 4.0.x i used to code the URL::action like this :
URL::action('DataController@getIndex',array($domain, 'sowhat'));

and the output will be like data\sowhat
now in 4.1.x, the same code will generate : data?sowhat
i know am using a bad habit for Route::controller('data','DataController');
but is this the expected behavior from the URL::action ?

im using route controller and i wanted {{URL::action('SiteBrowsePackageController@getIndex',['category'=>'special'])}}  query string instead /index/special .... any thought?