[Crushing] Cannot read property 'endsWith' of undefined] @1.34.4

Current Behavior
App crashed when I use the ListItem components. But if I downgrade the version from 1.34.4 to 1.34.2, everything goes well.
Expected Behavior
Don't crash.
And here are some my findings.

It looks like caused by this commit.

If I downgrade the version from 1.34.4 to 1.34.2, everything goes well.

Tamagui Version
"@tamagui/animations-react-native": "1.34.4",
"@tamagui/animations-reanimated": "1.34.4",
"@tamagui/babel-plugin": "1.34.4",
"@tamagui/config": "1.34.4",
"@tamagui/font-inter": "1.34.4",
"@tamagui/lucide-icons": "1.34.4",
"@tamagui/theme-base": "1.34.4",
"@tamagui/toast": "1.34.4",
"tamagui": "1.34.4",

Reproduction
> git clone https://github.com/Crossbell-Box/xLog-mobile.git
> git checkout develop
> yarn
> yarn run prebuild:dev
> yarn ios/android -d // Select the second bottom tab when App launched.

### System Info

```markdown
System:
    OS: macOS 14.0
    CPU: (10) arm64 Apple M1 Max
    Memory: 17.18 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.14.2 - ~/.nvm/versions/node/v18.14.2/bin/node
    Yarn: 1.22.19 - ~/Library/pnpm/yarn
    npm: 9.5.0 - ~/.nvm/versions/node/v18.14.2/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 114.0.5735.198
  npmPackages:
    @apollo/client: ^3.7.16 => 3.7.16
    @babel/core: ^7.21.8 => 7.21.8
    @babel/plugin-proposal-class-properties: ^7.18.6 => 7.18.6
    @babel/plugin-proposal-private-methods: ^7.18.6 => 7.18.6
    @babel/plugin-proposal-private-property-in-object: ^7.21.0 => 7.21.0
    @babel/plugin-transform-flow-strip-types: ^7.21.0 => 7.21.0
    @babel/preset-react: ^7.18.6 => 7.22.5
    @babel/preset-typescript: ^7.21.5 => 7.22.5
    @changesets/apply-release-plan: ^6.1.3 => 6.1.3
    @changesets/changelog-git: ^0.1.14 => 0.1.14
    @changesets/cli: ^2.26.1 => 2.26.1
    @changesets/config: ^2.3.0 => 2.3.0
    @changesets/get-release-plan: ^3.0.16 => 3.0.16
    @changesets/types: ^5.2.1 => 5.2.1
    @crossbell/contract: 1.5.0 => 1.5.0
    @crossbell/indexer: 1.5.0 => 1.5.0
    @crossbell/react-account: 1.5.0 => 1.5.0
    @crossbell/util-hooks: 1.5.0 => 1.5.0
    @dohooo/eslint-config: ^0.0.7 => 0.0.7
    @ethersproject/providers: ^5.7.2 => 5.7.2
    @ethersproject/shims: ^5.7.0 => 5.7.0
    @gorhom/bottom-sheet: 4.4.5 => 4.4.5
    @manypkg/get-packages: ^1.1.3 => 1.1.3
    @nomiclabs/hardhat-ethers: ^2.2.3 => 2.2.3
    @nomiclabs/hardhat-waffle: ^2.0.6 => 2.0.6
    @openzeppelin/contracts: ^4.8.3 => 4.8.3
    @react-native-async-storage/async-storage: 1.18.2 => 1.18.2
    @react-native-community/netinfo: 9.3.10 => 9.3.10
    @react-native-firebase/analytics: ^18.1.0 => 18.1.0
    @react-native-firebase/app: ^18.1.0 => 18.1.0
    @react-navigation/bottom-tabs: ^6.5.8 => 6.5.8
    @react-navigation/drawer: ^6.6.3 => 6.6.3
    @react-navigation/native: ^6.1.7 => 6.1.7
    @react-navigation/native-stack: ^6.9.13 => 6.9.13
    @react-navigation/stack: ^6.3.17 => 6.3.17
    @sentry/cli: ^2.19.1 => 2.19.1
    @sentry/react-native: 5.5.0 => 5.5.0
    @shopify/flash-list: 1.4.3 => 1.4.3
    @showtime-xyz/tab-view: ^0.1.7 => 0.1.7
    @tamagui/animations-react-native: 1.34.2 => 1.34.4
    @tamagui/animations-reanimated: 1.34.2 => 1.34.4
    @tamagui/babel-plugin: 1.34.2 => 1.34.4
    @tamagui/config: 1.34.2 => 1.34.4
    @tamagui/font-inter: 1.34.2 => 1.34.4
    @tamagui/lucide-icons: 1.34.2 => 1.34.4
    @tamagui/theme-base: 1.34.2 => 1.34.4
    @tamagui/toast: 1.34.2 => 1.34.4
    @tanstack/react-query: ^4.29.7 => 4.29.7
    @tanstack/react-query-persist-client: ^4.29.7 => 4.29.7
    @tradle/react-native-http: ^2.0.1 => 2.0.1
    @types/node: ^20.2.3 => 20.2.3
    @types/react: ~18.2.14 => 18.2.14
    @walletconnect/modal-react-native: ^1.0.0-rc.6 => 1.0.0-rc.6
    apollo3-cache-persist: ^0.14.1 => 0.14.1
    babel-plugin-module-resolver: ^5.0.0 => 5.0.0
    babel-plugin-transform-inline-environment-variables: ^0.4.4 => 0.4.4
    babel-polyfill: ^6.26.0 => 6.26.0
    base-64: ^1.0.0 => 1.0.0
    big-integer: ^1.6.51 => 1.6.51
    browserify-zlib: ^0.1.4 => 0.1.4
    buffer: ^6.0.3 => 6.0.3
    burnt: ^0.11.4 => 0.11.4
    crossbell: ^1.4.2 => 1.4.2
    crypto-js: ^4.1.1 => 4.1.1
    dayjs: 1.11.7 => 1.11.7
    dns.js: ^1.0.1 => 1.0.1
    dotenv: ^16.0.3 => 16.0.3
    dotenv-types-generator: ^1.1.2 => 1.1.2
    eslint: ^8.38.0 => 8.38.0
    ethereum-waffle: ^4.0.10 => 4.0.10
    ethers: ^5.6.8 => 5.7.2
    events: ^1.1.1 => 1.1.1
    expo: ^49.0.0 => 49.0.3
    expo-application: ~5.3.0 => 5.3.0
    expo-build-properties: ~0.8.3 => 0.8.3
    expo-clipboard: ~4.3.0 => 4.3.0
    expo-constants: ~14.4.2 => 14.4.2
    expo-crypto: ~12.4.1 => 12.4.1
    expo-dev-client: ~2.4.6 => 2.4.6
    expo-device: ~5.4.0 => 5.4.0
    expo-file-system: ~15.4.2 => 15.4.2
    expo-font: ~11.4.0 => 11.4.0
    expo-haptics: ~12.4.0 => 12.4.0
    expo-image: ~1.3.2 => 1.3.2
    expo-linear-gradient: ~12.3.0 => 12.3.0
    expo-linking: ~5.0.2 => 5.0.2
    expo-localization: ~14.3.0 => 14.3.0
    expo-media-library: ~15.4.0 => 15.4.0
    expo-notifications: ~0.20.1 => 0.20.1
    expo-splash-screen: ~0.20.4 => 0.20.4
    expo-status-bar: ~1.6.0 => 1.6.0
    expo-system-ui: ~2.4.0 => 2.4.0
    expo-updates: ~0.18.10 => 0.18.10
    expo-web-browser: ~12.3.2 => 12.3.2
    graphql: ^16.7.1 => 16.7.1
    hardhat: 2.0.6 => 2.0.6
    https-browserify: ^0.0.1 => 0.0.1
    husky: ^8.0.0 => 8.0.3
    i18next: ^22.4.15 => 22.4.15
    intl-pluralrules: ^2.0.0 => 2.0.0
    lottie-react-native: 5.1.6 => 5.1.6
    mdast-util-toc: ^6.1.1 => 6.1.1
    net: ^1.0.2 => 1.0.2
    node-libs-expo: ^0.0.3 => 0.0.3
    npm-run-all: ^4.1.5 => 4.1.5
    patch-package: ^6.4.7 => 6.5.1
    path-browserify: 0.0.0 => 0.0.0
    pinyin-pro: ^3.14.0 => 3.14.0
    punycode: ^1.4.1 => 1.4.1
    qrcode: ^1.5.1 => 1.5.2
    react: 18.2.0 => 18.2.0
    react-content-loader: ^6.2.1 => 6.2.1
    react-dom: ^18.2.0 => 18.2.0
    react-i18next: ^12.2.2 => 12.2.2
    react-native: 0.72.1 => 0.72.1
    react-native-color-matrix-image-filters: ^6.0.3 => 6.0.3
    react-native-crypto: ^2.2.0 => 2.2.0
    react-native-device-info: ^10.6.0 => 10.6.0
    react-native-drawer-layout: ^3.2.0 => 3.2.0
    react-native-gesture-handler: ~2.12.0 => 2.12.0
    react-native-get-random-values: ^1.8.0 => 1.8.0
    react-native-highlight-words: ^1.0.1 => 1.0.1
    react-native-keyboard-controller: 1.4.4 => 1.4.4
    react-native-level-fs: ^3.0.1 => 3.0.1
    react-native-modal: ^13.0.1 => 13.0.1
    react-native-os: ^1.2.6 => 1.2.6
    react-native-pager-view: 6.2.0 => 6.2.0
    react-native-progress: ^5.0.0 => 5.0.0
    react-native-qrcode-svg: ^6.2.0 => 6.2.0
    react-native-quick-base64: 2.0.5 => 2.0.5
    react-native-randombytes: ^3.6.1 => 3.6.1
    react-native-reanimated: ~3.3.0 => 3.3.0
    react-native-reanimated-carousel: ^3.5.1 => 3.5.1
    react-native-redash: ^18.1.0 => 18.1.0
    react-native-safe-area-context: 4.6.3 => 4.6.3
    react-native-screens: ~3.22.0 => 3.22.1
    react-native-sensors: ^7.3.6 => 7.3.6
    react-native-shadow-2: ^7.0.7 => 7.0.7
    react-native-svg: 13.9.0 => 13.9.0
    react-native-url-polyfill: ^1.3.0 => 1.3.0
    react-native-view-shot: 3.7.0 => 3.7.0
    react-native-web: ~0.19.6 => 0.19.6
    react-native-webview: 13.2.2 => 13.2.2
    readable-stream: ^1.0.33 => 1.0.34
    rehype-infer-description-meta: ^1.1.0 => 1.1.0
    rehype-stringify: ^9.0.3 => 9.0.3
    remark-frontmatter: ^4.0.1 => 4.0.1
    remark-parse: ^10.0.1 => 10.0.1
    remark-rehype: ^10.1.0 => 10.1.0
    remove-markdown: ^0.5.0 => 0.5.0
    rn-nodeify: ^10.3.0 => 10.3.0
    semver: ^7.5.0 => 7.5.0
    sentry-expo: ~7.0.0 => 7.0.1
    stream-browserify: ^1.0.0 => 1.0.0
    string_decoder: ^0.10.31 => 0.10.31
    strip-markdown: ^5.0.1 => 5.0.1
    tamagui: 1.34.2 => 1.34.4
    timers-browserify: ^1.4.2 => 1.4.2
    ts-essentials: ^9.3.1 => 9.3.2
    ts-node: ^10.9.1 => 10.9.1
    typescript: ^5.1.3 => 5.1.6
    unidata.js: 0.8.0 => 0.8.0
    unified: ^10.1.2 => 10.1.2
    url: ^0.10.3 => 0.10.3
    util: ~0.10.3 => 0.10.4
    viem: ^1.2.14 => 1.2.14
    vitest: ^0.30.1 => 0.30.1
    vm-browserify: ^0.0.4 => 0.0.4
    web3: ^1.10.0 => 1.10.0

OMG, I found a mistake...

BTW, I think there some people use the same approach to modify the tokens as me and the App didn't crash until 1.34.4.

Maybe we can modify this line to tell user must use this function to create tokens.


Enzyme is not working correctly in<EMAIL_ADDRESS>

I've created the issue in react-native repo earlier. However, I feel like this also belongs to enzyme.
Current behavior
When I upgraded my project to<EMAIL_ADDRESS>more than 50% of my tests break and some of them even throw not finding shallow method in enzyme. I am very confused why this is occurring.
Expected behavior
Test to succeed.

API

[✓ ] shallow
[ ] mount
[ ] render

Version
package.json

library
version

enzyme
3.8.0

react
1.8.0

react-dom
16.6.3

react-test-renderer
16.6.3

adapter (below)
enzyme-adapter-react-16

Adapter

[✓ ] enzyme-adapter-react-16
[ ] enzyme-adapter-react-16.3
[ ] enzyme-adapter-react-16.2
[ ] enzyme-adapter-react-16.1
[ ] enzyme-adapter-react-15
[ ] enzyme-adapter-react-15.4
[ ] enzyme-adapter-react-14
[ ] enzyme-adapter-react-13
[ ] enzyme-adapter-react-helper
[ ] others ( )

@ljharb I've found the solution. I had to mock like below in jestSetup in previous react-native version when using react-navigation@3 because react-native-gesture-handler was newly added and didn't mock well itself.
NativeModules.UIManager = {
  RCTView: () => ({
    directEventTypes: {},
  }),
};

When I remove above, everything works fine.


Cannot create multiple power sensor based on the same entity

On my electrical panel, I installed ammeter clamps on several groups of circuits. I have a circuit on which I have a hob, my internet box, my intercom and my washing machine.
My washing machine is plugged into a metered outlet.
I would like to create a virtual meter for the other 3 devices. I know the consumption of my box and that of my intercom. And I can finally deduce that of my hob.
Here is my code

But i have this error :
ERROR (MainThread) [custom_components.powercalc.sensor] sensor.id3_power: This entity has already configured a power sensor
How can i create multiple sensor based on the same entity.

Ok. Thanks a lot.

released in latest beta.


feat(card): finish card as design

Checklist

[x] Fix linting errors
[x] Tests have been added / updated (or snapshots)

Change information

:tada: This PR is included in version 1.0.0-alpha.34 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


update information for docker run options

update information for docker run options.

I'll close this PR per my comment above, but thanks again for contributing

ok :)


refactor(csv): move temp file removal to finally block, logging

SUMMARY

move temp file removal to finally block
log upload exception and log a warning when temp file cannot be removed

Closing due to inactivity


Advanced Endpoint Configuration Unable to Save

I'm currently test driving WSO2 API Manager 2.0.0. I'm trying to save changes to the Advanced Endpoint Configuration under step 2 of the API creation (from the publishing portal), but I'm not seeing the changes being saved. You can access the Advanced Endpoint Configuration by clicking the "setting" icon either in Production Endpoint row or Sandbox Endpoint row.

We have done fixes to the latest code.


VertexDecl and skip() issue

I need VertexDecl::skip() functionality.  After applying this simple patch: https://gist.github.com/velkyel/c60200741e04940e3a377d26345d6421
then VectorDisplay doesn't render anything.  Why?
Declaration dump on stdout looks ok:
vertexdecl 5ac33c65 (4376ca43), stride 36
    attr 0 - Attrib::Position, num 3, type 4, norm 0, asint 0, offset 0
    attr 4 - Attrib::Color0, num 4, type 0, norm 1, asint 0, offset 32
    attr 8 - Attrib::TexCoord0, num 2, type 4, norm 0, asint 0, offset 24

Wrong bgfx API usage?

Looking into it...

This was bad code, mixing PosColorUvVertex and point_t. I unified these structs, and now skip should work there.


Error handling questions

In my code I catch boost::system::system_error. That works great for boost::asio::error::operation_aborted or boost::asio::error::eof, but since it looks like you map beast errors onto boost::system::system_error how do I distinguish the regular boost asio errors from beast http errors in my catch blocks? I don't know what boost::asio::error::whatever has the same value as what beast is throwing.

I believe you get the error_code out of the system_error and when you make the comparison using error_code, the implementation of error_code checks to see that the error_category associated with the error_code is the same as the error_category associated with the enum. Thats what user defined make_error_code is for, so the implementation of error_code can make the comparison. I believe it is okay for enum values from different error categories to overlap. See:
https://github.com/vinniefalco/Beast/blob/master/include/beast/websocket/impl/error.ipp#L16
Now I could be wrong about this, because the whole error_code and system_error thing is highly confusing and not particularly well explained.
Note that for HTTP, only basic_parser_v1 throws custom error codes, the rest will be the errors thrown by asio. http::write and http::async_write will return boost::asio::error::eof if the message indicates that the connection should be closed afterwards. I might change that.

I've tested my server with junk input and it throws exceptions like "invalid method" (at least that's what an older version of beast did), which definitely aren't boost::asio::error::??? errors, but I can't figure out what error code namespace/name I should be checking for in my boost::system::system_error catch() block. I test for error::eof and error::operation_aborted, for example.

This should work:
try
{
    ...
}
catch(boost::system::system_error const& se)
{
    if(se.code() == beast::http::parse_error::bad_method)
        std::cerr << "You got a bad method!\n";
    else if(se.code() == boost::asio::error::eof)
        std::cerr << "End of file reached\n";
    else
        std::cerr << "Some other problem\n";
}

Thanks. That must be relatively new, I don't recall seeing beast::http::parse_error::bad_method anywhere.

Ah yes, you're right about that. When Beast was using the nodejs http-parser, it had an error_category that pulled its strings from there:
https://github.com/vinniefalco/Beast/blob/4cfa1d5cd34533caf4930455c6d3817b3bd00e89/include/beast/http/detail/error.hpp#L28

There's a Gitter chat room for Beast available now:


How to set up the config file for version 0.7 (as a release)

I couldn't get the v0.6 release to work with Elixir 1.6 and Erlang 20, so I cloned the Poxa repo, downloaded dependencies and generated the release. Finally I was going to run it as a daemon, but I needed to set up the config and there was no "releases" folder.
I found a config folder instead, and this had 4 files: config.exs, poxa.dev.conf poxa.prod.conf and poxa.schema.exs.
Some of those files had similar settings in them, and I am not sure which ones take precedence. Am I meant to copy the poxa.dev.conf file to poxa.conf and then fill out the config details? Or just use the poxa.dev.conf file directly.
Thanks

Hey! Recently I did some refactor on the way we publish releases and the README.md is not 100% done. I should be able to finish this weekend and finally release a new version.
The release directory is now inside _build and yeah the conf is now per environment. You can find some generic docs here: https://hexdocs.pm/distillery/getting-started.html and here: https://hexdocs.pm/conform/getting-started.html
Sorry for the confusion!

Great! I figured the docs were outdated but I tried to wing it anyway. I have checked out the links about Hex but I couldn't figure out what I needed to change, by myself as I'm pretty new to it. I will wait for the weekend release, then. Thank you.

Cool I just updated the README with more info. Can you check if it's enough? My last step is fixing the docker build part. It's almost 100% but I still may need to do some tweaks. Then finally release 0.7.0


Why is the library more command line oriented ?

I am wondering what's the philosophy behind the way the library is developed, why is it more oriented for command line use rather than interactive python use (more like pytorch, imagine if pytorch was only command line).
There isn't many examples on how to fine-tune / train using solely python without command line. Is it possible to do that using the Library, or does this need new modules ? Doing that would help in experimenting with models, and with new ideas.
Sorry for my newbie question, but that's all I could think of when I'm learning how to use fairseq!

Towards your second question, I've found this to be very helpful, even if you aren't using ray:
Fault-Tolerant Fairseq Training

Hi! I've been using Fairseq for a while, and I still feel the same way as you @maroxtn. It's an interesting discussion, I'll subscribe to receive notifications 👌


[DOCS] Docker Support

Add a section to the environments page outlining best practices for working with FiftyOne inside docker. We may want to consider also providing pre-built docker images of FiftyOne.

Prebuilt Docker images would be great 🙂 but even a well-tested Dockerfile would be great. It would allow me to take FiftyOne for a test drive! Running the image with something like
docker run -it -p 8080:8080 -v `pwd`/mydata:/fiftyone/data voxel51/fiftyone:latest

should work even for remote servers.

Tried to bring a container up and running myself. It has a similar structure as the one from @Data-drone . It is running by the logs, but I cannot access on via browser. Any help would be very appreciated!
Dockerfile:
FROM python:3.10-buster
RUN pip install fiftyone==0.16.6
ENTRYPOINT ["python", "-c", "import fiftyone; session = fiftyone.launch_app(port=8082); session.wait()"]

docker build -t fiftyone:latest .
docker run -it -d -p 8082:8082 fiftyone:latest


Claudia: Fix deletion of accounts - GSuite

GSuite accounts are scheduled for deletion in the website when it is no longer needed, and should be deleted after a certain time period. However, the last part has not been implemented yet so old accounts are not removed. We should create a command to delete the gsuite account, and add a cronjob to trigger it periodically, probably with some help from the syscom.

See also #547


Year progressions

I don't understand what the issue is you are trying to explain.

Same to me. What does this panel:

This panel displays your progress for each beginning of year to current month and day. Today is March 20th, this panel shows "What I've accomplished by March 20th of this year compared to previous years to the same date."

My mistake. I was thinking that all rows is comparison to this year. Now I understand what means "Δyear-1".


Need a meaningful name for wso2_sp_dashboard

Pack - beta2
It is better to give a meaningful name for wso2_sp_dashboard

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


Update to use windows-latest as the build agent image

PR Summary
Update to use windows-latest as the build agent image for CI, because the windows-2016 is being deprecated.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.

There are 3 other files that need to be updated: windows-test.yml, windows-packaging.yml, PSGalleryToAzArtifiacts.yml

/backport to release/v7.0.11

https://github.com/PowerShell/PowerShell/commit/75205b8096be1d0a345dfac5904ef6110b359c01

/backport to release/v7.2.5


Use spotify/docker-uhttpd instead of fnichol/docker-uhttpd

to avoid problems if upstream makes breaking changes.

I think that's all of the upstreams we need to take care of. There's busybox, but since it's an official image, I think the likelihood of breakage is low.

Current coverage is 50.54% (diff: 100%)

Merging #1003 into master will not change coverage

@@             master      #1003   diff @@
==========================================
  Files           279        279
  Lines         13096      13096
  Methods           0          0
  Messages          0          0
  Branches       1687       1687
==========================================
  Hits           6619       6619
  Misses         5976       5976
  Partials        501        501

Powered by Codecov. Last update c6779ee...4ef8ba6

And the rohan/ images too.

SGTM

btw where are we storing the Dockerfiles for these new images? we should create a new repo under spotify org to house them.

I haven't done that yet. We can do that separately.

I've just pulled, retagged, pushed. I haven't done anything with the
Dockerfiles.
On Tue, Oct 25, 2016 at 10:30 AM, Matt Brown<EMAIL_ADDRESS>wrote:

btw where are we storing the Dockerfiles for these new images? we should
create a new repo under spotify org to house them.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/spotify/helios/pull/1003#issuecomment-256051502, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAdVbVZpejQeBIo-FbWjE63d9ymqk9vzks5q3hKhgaJpZM4KfebM
.

--
David Xia
Software Engineer
<EMAIL_ADDRESS>


PowerToys have not been updated for a long time.

PowerToys have released version 0.25.0, but only the 0.21.0 is available in the bucket.
https://github.com/microsoft/PowerToys/releases
https://github.com/lukesampson/scoop-extras/commits/master/bucket/powertoys.json

That's probably because the installer was changed from an MSI installer to EXE with version 0.23. Looks like the new one is no longer "portable", but that would need to be checked.
PowerToysSetup-0.25.0-x64.exe --silent --skip_dotnet_install --no_start_pt --log_level error

FYI, v0.29, released today, allows custom location flags.

Thanks for the info, I will check if this makes it "scoopable" again.

@Sn0wCrack was quicker than me, happy to see this working again!

@Sn0wCrack was quicker than me, happy to see this working again!


feat: merge suspensions into bans

This PR merges the suspensions system into the ban system. Bans can now have a duration (null means they're permanent) and can be extended by using the extend route. Only non permanent bans can be extended and tempbans can have a length of up to 7 days.
Resolves #239

Due to an incorrect migration in #170, the user ID columns were made nullable. In this PR I originally made the user IDs not nullable in the down method but reverted that in https://github.com/guidojw/arora-api/pull/246/commits/7085c0ed148d812a670cde5afbe49895c02fad73, will open a PR to fix that later.


Uniqueness blocks deployment even with minimumHealthCapacity=0

Marathon 0.10.0, Mesos 0.23.0, single slave <IP_ADDRESS>". The following application is able to start, but you cannot restart it, even though minimumHealthCapacity set to 0 permits Marathon to kill existing task. If you drop ["hostname", "UNIQUE"], restarts work as expected.
{
  "id": "/test",
  "cmd": "sleep 1800",
  "instances": 1,
  "mem": 16,
  "cpus": 0.1,
  "env": {
    "v": "3"
  },
  "minimumHealthCapacity": 0,
  "constraints": [
    ["hostname", "UNIQUE"],
    ["hostname", "CLUSTER", "<IP_ADDRESS>"]
  ]
}

I also don't understand why #689 states that with 3 nodes you have to set minimumHealthCapacity to  0.3 to update anything. With anything above 2/3 (0.66) Marathon should be able to kill one instance and start new one at the same host.

@bobrik shouldn't the minimumHealthCapacity field be under upgradeStrategy in your app definition?
See https://mesosphere.github.io/marathon/docs/rest-api.html#upgradestrategy

Yep, my mistake. Is there an issue to warn users about unknown fields in app definitions? I'd love to use "strict" mode for deployment when apps with extra fields are rejected.

We are thinking about something along those lines – thanks for your input!

@bobrik I've also been thinking about a strict mode for a while.
So I just created the following issue: #2164 - Add a "strict" mode.

:+1:


Add before request handler to log info about session

Short Description
We had some potential problems with the session cookie for Flask Login. This should give more insight into
Changes

Add  before request handler

Feedback

Does this need tests?
Do you see any potential leakage? I decided to also logg if the user is in the database, do you see any problem with that (also potential exceptions)?
Is anything worth logging missing?

How to review this Pull Request
Link to Confluence (internal)

Code smell is because of the inner function. I think it might be more readable that way. WDYT?


Update order messes up stuff

The order that the world updates makes lots of behaviours weird. Change to track which cells have updated, and stop them acting twice? Find a better update order?

Even something as simple as this doesn't work as 'intended':

I changed the default to RANDOM_CYCLIC (untagged). Probably the simplest solution for the moment. In the future, I want to investigate ATOM_ORDERED more!


HikariPool: Log consitency

HikariPool: Log consitency
PoolElf: I think two more round trips to db/driver is overkill (for pool
to support bad driver) especially jdbc spec reads 'closing statement
must close any current result set'. It is already slow (compare to
others) having network timeout as well as query timeout to validate
connection!

done and some more but it is failing tests:
Failed tests:
ShutdownTest.testAfterShutdown:228 null
Tests in error:
TestValidation.validateBothDriverAndDS:183 » IllegalArgument cannot use driver...
TestValidation.validateMissingUrl:59 » IllegalArgument jdbcUrl is required wit...

anything more required for merging ?


Improve message if uffizzi unable to log in to docker registry.

Go into CLI
Sign in
Try to connect any docker-registry (ecr, acr, etc..) using invalid credentials (run: bundle exec uffizzi connect docker-hub)

Result:
Message: We were unable to log you in to docker registry. Please verify that your username and password are correct.
Suggestion: Specify which docker registry we can't log in to.
In GHA it is hard to understand, which connection was failed:

Test result:

@JessikaCastellano Please test and attach screenshots of cases when a custom docker registry is used.

Tests
DockerHub:

Azure:

Amazon:

Google:

GitHub Container Registry

Docker Registry:

@JessikaCastellano The objective of this task is not achieved - please look up the description
https://github.com/UffizziCloud/uffizzi_app/issues/264#issue-1381374784

New PR #283 open
Tests:
DockerHub

Azure

Amazon

Google

GitHub Container Registry

Docker Registry

TESTED on prod - OK
# uffizzi connect gcr google.json
We were unable to log you in to Google. Please verify that your username and password are correct.

# uffizzi connect docker-hub
Username: 12351
Password:
We were unable to log you in to DockerHub. Please verify that your username and password are correct.

# uffizzi connect ecr
Registry Domain: ***
Access key ID: c1234c
Secret access key:
We were unable to log you in to Amazon. Please verify that your username and password are correct.

# uffizzi connect ghcr
Github Username: NealArw
Access Token:
We were unable to log you in to Github Container Registry. Please verify that your username and password are correct.

For docker-registry issue created https://github.com/UffizziCloud/uffizzi/issues/295


OutputContainer: Open output with avio_open2 and pass "protocol_options"

Allows overriding protocol-specific options such as HTTP method and HTTP
retrial policy

Do note that this introduces a non-backward-compatible change in open by adding protocol_options in the middle of the argument-list. Accidents is mitigated by ensuring that any of the _options parameters must be given by name.
The alternative would be to add `protocol_options to the end, but it would look a bit messy.

Sorry, typo and sorry for long response-time. Updated the docstring and re-reviewed the PR myself. I think it's in order now.

HI @rawler! I have to admit I'm quite confused by the handling of "options" (even before your changes). We're asking the user for distinct options / container_options / protocol_options, then we're merging all these together. How come the new "protocol_options" cannot be passed via the existing "container_options"?

I definitely agree r.e. container vs. protocol-options (and global options). At some point, I think it needs to be cleaned up.
Container-options could not be used to pass protocol-options, since it was not passed to avio_open in OutputContainer. When making the PR, I considered just passing container-options to avio_open, but it felt wrong, solidifying the behavior of mixing all the options up. On the InputContainer-side however, we use avformat_open_input, which takes both protocol and container-options mixed, so enforcing separated options would be a breaking change. With this API, it's at least possible to write application-code that cleanly separates the types of options, (but also still possible to confuse them).
Another option could of course be to merge options back into a single parameter in the API. I think ffmpeg option names typically does not collide between protocol/container/codec.

I have to admit I'm still confused, you are passing the "protocol_options" to:

avio_open2
avformat_write_header
avformat_open_input

Which ones actually use them? I'm not convinced that we actually want to add protocol_options, it seems to be treated 100% like container_options, so I can't really tell what we gain in exchange for the breaking API change.

Sorry again for even slower response-time. Let me try it from a different angle.
What I really need is a way to pass options to avio_open2. Note that this is already done internally by avformat_open_input, so can already be done for input-containers, but I need a way to do it for output as well.
I can see a few different ways to achieve that;

Pass self.container_options. That somehow seems wrong. avio_open2 does not really deal with containers at all, just the underlying I/O-protocols.
Pass self.options to avio_open2. This would create different API:s where container_options reaches avio_open2 for InputContainer, but not for OutputContainer.
Pass self.options | self.container_options. Same problem as first, and unclear to me why we even have different option-structs if always we end up passing the union regardless?
Pass self.protocol_options alone to avio_open2. This would work, but again create an inconsistent API between InputContainer and OutputContainer where both would support practically the same arguments, but apply them differently.

At this point, I assume the reason we're passing self.options | self.container_options for InputContainer is basic case of backwards compatibility, while enabling/encouraging applications to start passing options separately? I'm guessing we'll at some point want to break that, but make it possible for applications to be rewritten first? (Otherwise, I've misunderstood the intention with container_options.)
Given the above assumption what this PR is trying to do is; Add separate options for the 3d layer of the stack (Codecs, Containers, I/O Protocols), while not breaking backwards compatibility, and ensuring that the API remains consistent across InputContainer and OutputContainer.

Given that avformat_open_input already have passed self.options | self.container_options to avio_open2, we must keep doing that, or risk breaking stuff.
Given that we want to start separating protocol_options, we now allow applications to pass it in separately, and can (at some later point) deprecate it being passed to the "wrong" layer.

On the flip-side; if we don't want to enable applications to pass protocol-options separately and explicitly, why do we want it for container-options?

Too old.


Translations should only be re-generated on request

Currently the translations get extracted on every run - which results in changes for all the nice .po files over and over again. Even if nothing changed.

The files are indeed changed whenever a line "moves" in a source file (due to deletion or insertion of lines). The actual translations are not changed, but the new location is added to the comments of the translation rather than updating the line number.
Perhaps completely rewriting the .po files would work. With the old tool chain the translations weren't automatically updated either, so @cajus 's suggestion sounds reasonable.

please see new --update-po-files argument (in next PR)

As discussed on gitter, right now, changes of strings are not tracked if the new option is not provided, and in fact, no translation files are ever created even the first time without that option. The proposal, instead, is to update strings in the .po file automatically, but only update the line numbers if the special option is specified. Alternatively, a compile-time flag can allow leaving the line numbers out entirely. The line numbers are required by the standard, but are not required by many po editors.


No judges found!

WARN  [proxy_rs::checker] Not found judges for the ["HTTP", "HTTPS"] schemes. Checking proxy on protocols ["CONNECT:25", "HTTPS", "HTTP", "SOCKS5", "CONNECT:80", "SOCKS4"] is disabled.
ERROR [proxy_rs::checker] No judges found!

I tried cargo install proxy-rs and cargo install --git https://github.com/zevtyardt/proxy.rs.git

Can you try it again with the --log debug flag

This is as much as I can give you, the log is too long to get anything above this
https://pastebin.com/yJTMVFzV

I have added a new version, you can try it

It works now, thanks!


JSON Serialization Potential Bug In Behavior Examples

Hello SVL,
I have installed the igibson sim, bddl, and behavior benchmark as per the instructions provided at https://docs.google.com/document/d/1u2m9Ld6Qo3eG-fvCzuAZN6lHxwpVVBlwLVdzo_WDlNI. I can also instantiate the behavior simulator and see both the environment PyBullet is rendering, and the robot models.
However, the install check provided in the doc does not work for me.
I'm running: python iGibson/igibson/examples/behavior/behavior_env_metrics.py.
However, this command exits with an error after running for a while:
Traceback (most recent call last):
  File "iGibson/igibson/examples/behavior/behavior_env_metrics.py", line 95, in <module>
    json.dump(per_episode_metrics, file)
...
TypeError: Object of type float32 is not JSON serializable

I think my installation of the simulator is correct, as per_episode_metrics is populated with data seemingly correctly. Perhaps there is a bug in how the episode data is being written to JSON (should it be converted to a list first?).
Best,
Brandon

This will be fixed in the next release (the json in this example was only for didactic purposes).
If you want to patch your local install you can apply the following patch.
diff --git a/igibson/metrics/agent.py b/igibson/metrics/agent.py
index fe195c65..1ebb8d80 100644
--- a/igibson/metrics/agent.py
+++ b/igibson/metrics/agent.py
@@ -160,7 +160,7 @@ class FetchRobotMetric(MetricBase):
         gripper_distance = np.abs(delta_pos)
         self.delta_agent_distance["gripper"].append(gripper_distance)

-        self.agent_local_pos["gripper"].append(list(robot.get_relative_eef_position()))
+        self.agent_local_pos["gripper"].append(robot.get_relative_eef_position().tolist())

         contacts = p.getContactPoints(bodyA=robot.robot_ids[0], linkIndexA=robot.eef_link_id)
         if len(contacts) > 0:


[test-integration] Fix Should finish the preemption when the jobset becomes inactive

…ecomes inactive

What type of PR is this?
/kind bug
/kind flake

What this PR does / why we need it:
[test-integration] Fix Should finish the preemption when the jobset becomes inactive
Which issue(s) this PR fixes:

Fixes #2808
Special notes for your reviewer:
Does this PR introduce a user-facing change?

None

/lgtm
/approve
/cherry-pick release-0.8
To make the release branch more stable

Ah the test was added after 0.8: https://github.com/kubernetes-sigs/kueue/pull/2603. No need to cherry-pick.


AutoGEMM problem(s) on NVIDIA Hardware

I'm trying to compare the clBLAS library with cuBLAS on an Nvidia K20c. Building clBLAS turns out to be fine so far, the measurements with the included client are resulting in about 610 GFLOPS (for dgemm, m, n and k are 4096 for this case), which is about 55% peak performance. I've been trying to improve this result by using the AutoGEMM Profiler as stated in the wiki to use the fastest kernels on this GPU. After getting it to work for NVIDIA OpenCL Platforms (by changing the hard-coded PLATFORM_NAME in the code of the profiler) it seemed to be working, but I am not quite sure if the output file is complete, because it seems to be missing some data. The following lines are directly taken from the file prof_sgemm_ksr.txt generated by the Autogemm_Tools_Profile executable:
[  384, [ 48, 48], [ [ 64, 64], [ 48, 48] ] ],
[  400, [ 32, 32], [ [ 64, 64], [ 48, 48], [ 80, 80] ] ],
[  416, [ 32, 32], [ [ 64, 64], [ 48, 48], [ 80, 80], [ 32, 32] ] ],
[  464, [ 80, 80], [ [ 64, 64], [ 48, 48], [ 80, 80], [ 32, 32] ] ],

According to the wiki this should be the kernel selection data (for sgemm in this case), but compared to the included kernelSelectionData in AutoGemmParameters.py, there are 2 elements missing in each inner list (taken from kernelSelectionDataHawaii):
[ 4000, [ 16, 16,  6,  6], [ [ 16, 16,  6,  6] ] ],
[ 2496, [ 16, 16,  4,  4], [ [ 16, 16,  6,  6], [ 16, 16,  4,  4] ] ],
[ 2448, [ 16, 16,  6,  6], [ [ 16, 16,  6,  6] ] ],

Correct me if I'm wrong, but I think that the values for the microtile dimensions are missing. I am not quite sure if this related to the fact that I'm using NVIDIA Hardware, but I don't know what to do with the generated data at this point. I cant include this data to the AutoGemmParameters.py script, because it references the missing elements.
tl;dr: Is it possible to use AutoGEMM on NVIDIA Hardware or am I "stuck" with the default kernels?
Edit: I just realised I forgot to mention: I'm using a CentOS 7.1 System, if that is relevant for this problem.

Hi, Billy:
I guess I can use a few words to summary what you are doing.
        Tuning AutoGEMM on Nvidia card.

Regarding to two elements missing. you want to change them like this
[  384, [ 48, 48], [ [ 64, 64], [ 48, 48] ] ], --> [  384, [ 16, 16,
3, 3 ], [ [ 16, 16, 4, 4], [ 16, 16, 3, 3] ] ],
On Wed, Jan 20, 2016 at 6:17 AM, Billy Naumann<EMAIL_ADDRESS>wrote:

I'm trying to compare the clBLAS library with cuBLAS on an Nvidia K20c
Building clBLAS turns out to be fine so far, the measurements with the
included client are resulting in about 610 GFLOPS (for dgemm, m, n and k
are 4096 for this case), which is about 55% peak performance I've been
trying to improve this result by using the AutoGEMM Profiler as stated in
the wiki to use the fastest kernels on this GPU After getting it to work
for NVIDIA OpenCL Platforms (by changing the hard-coded PLATFORM_NAME in
the code of the profiler) it seemed to be working, but I am not quite sure
if the output file is complete, because it seems to be missing some data
The following lines are directly taken from the file prof_sgemm_ksrtxt
generated by the Autogemm_Tools_Profile executable:
[  384, [ 48, 48], [ [ 64, 64], [ 48, 48] ] ],
[  400, [ 32, 32], [ [ 64, 64], [ 48, 48], [ 80, 80] ] ],
[  416, [ 32, 32], [ [ 64, 64], [ 48, 48], [ 80, 80], [ 32, 32] ] ],
[  464, [ 80, 80], [ [ 64, 64], [ 48, 48], [ 80, 80], [ 32, 32] ] ],
According to the wiki this should be the kernel selection data (for sgemm
in this case), but compared to the included kernelSelectionData in
AutoGemmParameterspy, there are 2 elements missing in each inner list
(taken from kernelSelectionDataHawaii):
[ 4000, [ 16, 16,  6,  6], [ [ 16, 16,  6,  6] ] ],
[ 2496, [ 16, 16,  4,  4], [ [ 16, 16,  6,  6], [ 16, 16,  4,  4] ] ],
[ 2448, [ 16, 16,  6,  6], [ [ 16, 16,  6,  6] ] ],
Correct me if I'm wrong, but I think that the values for the microtile
dimensions are missing I am not quite sure if this related to the fact that
I'm using NVIDIA Hardware, but I don't know what to do with the generated
data at this point I cant include this data to the AutoGemmParameterspy
script, because it references the missing elements
tl;dr: Is it possible to use AutoGEMM on NVIDIA Hardware or am I "stuck"
with the default kernels?
—
Reply to this email directly or view it on GitHub
https://github.com/clMathLibraries/clBLAS/issues/220.

--
Tingxing dong

Thank you for your reply,

Tuning AutoGEMM on Nvidia card.

I guess that pretty much sums it up :+1:
After changing the lists as you described, the AutoGemmParameters script runs fine so far - everything builds without any errors. Unfortunately, the new kernels don't bring the improvements I was hoping for. Instead the sgemm performance drops from about ~1 TFLOPS down to ~200 GFLOPS (m, n and k are 4096 in this test, too).
Are there any other assumptions made within the profiler-code that could interfere with my Nvidia hardware?

In tuning GEMM. you should get two files.  prof_sgemm_ksr.txt and
prof_sgemm_raw.csv.
check the gflop/s number in .csv file of 4096 to see if it is 200?
On Thu, Jan 21, 2016 at 4:47 AM, Billy Naumann<EMAIL_ADDRESS>wrote:

Thank you for your reply,
Tuning AutoGEMM on Nvidia card.
I guess that pretty much sums it up [image: :+1:]
After changing the lists as you described, the AutoGemmParameters script
runs fine so far - everything builds without any errors. Unfortunately, the
new kernels don't bring the improvements I was hoping for. Instead the
sgemm performance drops from about ~1 TFLOPS down to ~200 GFLOPS (m, n and
k are 4096 in this test, too).
Are there any other assumptions made within the profiler-code that could
interfere with my Nvidia hardware?
—
Reply to this email directly or view it on GitHub
https://github.com/clMathLibraries/clBLAS/issues/220#issuecomment-173534439
.

--
Tingxing dong

There are multiple numbers in this file, I'm assuming for each tile size and unroll value. The line itself looks like this:

4096, 4096, 59.8307, 220.849, 240.196, 212.161, 461.437, 439.214, 334.463, 577.598, 590.172, 463.61, 741.16, 790.162, 556.23, 813.633, 941.988, 533.845, 1034.45, 1044.49, <-F|T->, 60.2822, 222.991, 240.973, 217.049, 466.821, 441.828, 0, 0, 0, 474.877, 760.203, 809.713, 0, 0, 0, 0, 0, 0, 96x96,

I've attached both generated outputfiles for comparison. For larger tile-sizes and unrolling-values the gflops value seems to be mostly increasing, even to a comparable level to the "original" input.
prof_sgemm_ksr.txt
prof_sgemm_raw.csv.txt

Yes, here the number means the gflop/s.  so the largest one  is 1044.49 at
96*96, which means, your should be able to obtain 1044.49 after you
finalized your setting.
Yet, I courage you to try another matrix size other than 1024, 2048, 4096.
These divisible tricky sizes are dealt with separately in cl GEMM on AMD
GPU.
It might be different on Nvidia GPU.
Don't check one particular size, plot a line.
On Fri, Jan 22, 2016 at 4:22 AM, Billy Naumann<EMAIL_ADDRESS>wrote:

There are multiple numbers in this file, I'm assuming for each tile size
and unroll value. The line itself looks like this:
4096, 4096, 59.8307, 220.849, 240.196, 212.161, 461.437, 439.214, 334.463,
577.598, 590.172, 463.61, 741.16, 790.162, 556.23, 813.633, 941.988,
533.845, 1034.45, 1044.49, <-F|T->, 60.2822, 222.991, 240.973, 217.049,
466.821, 441.828, 0, 0, 0, 474.877, 760.203, 809.713, 0, 0, 0, 0, 0, 0,
96x96,
I've attached both generated outputfiles for comparison. For larger
tile-sizes and unrolling-values the gflops value seems to be mostly
increasing, even to a comparable level to the "original" input.
prof_sgemm_ksr.txt
https://github.com/clMathLibraries/clBLAS/files/100618/prof_sgemm_ksr.txt
prof_sgemm_raw.csv.txt
https://github.com/clMathLibraries/clBLAS/files/100619/prof_sgemm_raw.csv.txt
—
Reply to this email directly or view it on GitHub
https://github.com/clMathLibraries/clBLAS/issues/220#issuecomment-173871175
.

--
Tingxing dong

https://github.com/tingxingdong/clBLAS-private/wiki/How-to-tune-clBLAS-GEMM


Fix test_package

As far as I understand, it lives in the build context, then text should run it from that env.
let me know if I'm wrong and we can find the proper solution :)
Also changed the flag to --version to have somethig to see in the output :)
Tested locally in macos, linux and windows

Duh! I was so used to using conanrun there it didn't cross my mind.  Thanks!


Cant' upload CSV that contains time field with : Delimiter

Make sure these boxes are checked before submitting your issue - thank you!

[X] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[X] I have reproduced the issue with at least the latest released version of superset.
[X] I have checked the issue tracker for the same issue and I haven't found one similar.

Superset version
from 0.28 to latest master
Expected results
csv with a time field that contains : Delimiter should upload without a problem
Actual results
I get the error TypeError: Object of type OperationalError is not JSON serializable
the error is
<IP_ADDRESS> - - [11/Nov/2018 17:07:24] "GET /csvtodatabaseview/form HTTP/1.1" 200 -
2018-11-11 17:07:24,993:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:24] "GET /csvtodatabaseview/form HTTP/1.1" 200 -
<IP_ADDRESS> - - [11/Nov/2018 17:07:25] "GET /superset/schemas_access_for_csv_upload?db_id=1 HTTP/1.1" 200 -
2018-11-11 17:07:25,478:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:25] "GET /superset/schemas_access_for_csv_upload?db_id=1 HTTP/1.1" 200 -
2018-11-11 17:07:27,107:DEBUG:root:[stats_logger] (incr) failed_csv_upload
<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "POST /csvtodatabaseview/form HTTP/1.1" 500 -
2018-11-11 17:07:27,117:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "POST /csvtodatabaseview/form HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/app.py", line 2309, in __call__
    return self.wsgi_app(environ, start_response)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/app.py", line 2295, in wsgi_app
    response = self.handle_exception(e)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/app.py", line 1741, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/_compat.py", line 35, in reraise
    raise value
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/app.py", line 2292, in wsgi_app
    response = self.full_dispatch_request()
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/app.py", line 1816, in full_dispatch_request
    return self.finalize_request(rv)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/app.py", line 1833, in finalize_request
    response = self.process_response(response)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/app.py", line 2114, in process_response
    self.session_interface.save_session(self, ctx.session, response)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/sessions.py", line 375, in save_session
    val = self.get_signing_serializer(app).dumps(dict(session))
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/itsdangerous.py", line 565, in dumps
    payload = want_bytes(self.dump_payload(obj))
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/itsdangerous.py", line 847, in dump_payload
    json = super(URLSafeSerializerMixin, self).dump_payload(obj)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/itsdangerous.py", line 550, in dump_payload
    return want_bytes(self.serializer.dumps(obj))
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/json/tag.py", line 296, in dumps
    return dumps(self.tag(value), separators=(',', ':'))
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/json/__init__.py", line 179, in dumps
    rv = _json.dumps(obj, **kwargs)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/simplejson/__init__.py", line 399, in dumps
    **kw).encode(obj)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/simplejson/encoder.py", line 296, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/simplejson/encoder.py", line 378, in iterencode
    return _iterencode(o, 0)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/flask/json/__init__.py", line 81, in default
    return _json.JSONEncoder.default(self, o)
  File "/Users/alganas/.pyenv/versions/3.6.6/envs/vanila/lib/python3.6/site-packages/simplejson/encoder.py", line 273, in default
    o.__class__.__name__)
TypeError: Object of type OperationalError is not JSON serializable
<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=style.css HTTP/1.1" 200 -
2018-11-11 17:07:27,133:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=style.css HTTP/1.1" 200 -
<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=jquery.js HTTP/1.1" 200 -
2018-11-11 17:07:27,134:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=jquery.js HTTP/1.1" 200 -
<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 200 -
2018-11-11 17:07:27,134:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 200 -
<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=ubuntu.ttf HTTP/1.1" 200 -
2018-11-11 17:07:27,163:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=ubuntu.ttf HTTP/1.1" 200 -
<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
2018-11-11 17:07:27,211:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
2018-11-11 17:07:27,262:INFO:werkzeug:<IP_ADDRESS> - - [11/Nov/2018 17:07:27] "GET /csvtodatabaseview/form?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -

Steps to reproduce
upload a csv file that have a field with date time formate  YYYY-MM-DDTHH:MM:SS

sorry my mistake. the problem cause by missing quotations in text feilds.
closing it now


scan_is_chars_list2 can return incorrect length for appended strings

Seems like scan_is_chars_list2 only counts the length of the first string 'chunk' after append/3, causing chars_list_to_string to overflow.
Sample program:
leak(String) :-
	append("/abc/", String, Dir),
	directory_files(Dir, Files),
	write(Dir),
	write(Files).

Valgrind report:
$ valgrind --leak-check=full tpl test.pl -g 'trace, leak("qwertyioup"), halt'
==4593== Memcheck, a memory error detector
==4593== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4593== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==4593== Command: tpl test.pl -g trace,\ leak("qwertyioup"),\ halt
==4593==
[user:1:f0:fp:1:cp0:sp0:hp0:tp0] EXIT trace
[user:3:f0:fp:1:cp0:sp0:hp0:tp0] CALL leak("qwertyioup")
[user:5:f1:fp:2:cp0:sp3:hp0:tp0] CALL append("/abc/","qwertyioup",_1)
[lists:7:f7:fp:8:cp0:sp24:hp0:tp0] EXIT append([],"qwertyioup","qwertyioup")
inc len: 1 (src = /)
inc len: 1 (src = a)
inc len: 1 (src = b)
inc len: 1 (src = c)
inc len: 1 (src = /)
inc len: 1 (src = /)
inc len: 1 (src = a)
inc len: 1 (src = b)
inc len: 1 (src = c)
inc len: 1 (src = /)
[user:9:f1:fp:8:cp0:sp24:hp0:tp0] CALL directory_files("/abc/qwert...",_2)
inc len: 1 (src = /)
inc len: 1 (src = a)
inc len: 1 (src = b)
inc len: 1 (src = c)
inc len: 1 (src = /)
cl2s put offset=1 len=5: /
cl2s put offset=2 len=5: a
cl2s put offset=3 len=5: b
cl2s put offset=4 len=5: c
cl2s put offset=5 len=5: /
cl2s put offset=6 len=5: q
==4593== Invalid write of size 1
==4593==    at 0x2189F8: put_char_utf8 (utf8.c:142)
==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)
==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd
==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)
==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==
cl2s put offset=7 len=5: w
==4593== Invalid write of size 1
==4593==    at 0x218838: put_char_bare_utf8 (utf8.c:107)
==4593==    by 0x2189E7: put_char_utf8 (utf8.c:141)
==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)
==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd
==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)
==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==
cl2s put offset=8 len=5: e
cl2s put offset=9 len=5: r
cl2s put offset=10 len=5: t
cl2s put offset=11 len=5: y
cl2s put offset=12 len=5: i
cl2s put offset=13 len=5: o
cl2s put offset=14 len=5: u
cl2s put offset=15 len=5: p
==4593== Invalid write of size 1
==4593==    at 0x1BA48A: chars_list_to_string (print.c:64)
==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==  Address 0x6bfa18f is 8 bytes after a block of size 7 alloc'd
==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)
==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==
==4593== Syscall param stat(file_name) points to unaddressable byte(s)
==4593==    at 0x4E874BA: _xstat (xstat.c:35)
==4593==    by 0x201E58: fn_directory_files_2 (streams.c:5500)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd
==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)
==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)
==4593==    by 0x1CE7B7: start (query.c:1725)
==4593==    by 0x1CF010: execute (query.c:1921)
==4593==    by 0x16EDA0: run (parser.c:3801)
==4593==    by 0x1C5208: pl_eval (prolog.c:127)
==4593==    by 0x11657E: main (tpl.c:280)
==4593==
inc len: 1 (src = /)
inc len: 1 (src = a)
inc len: 1 (src = b)
inc len: 1 (src = c)
inc len: 1 (src = /)
inc len: 1 (src = /)
inc len: 1 (src = a)
inc len: 1 (src = b)
inc len: 1 (src = c)
inc len: 1 (src = /)
   error(existence_error(directory,"/abc/qwertyioup"),directory_files/2).
==4593==
==4593== HEAP SUMMARY:
==4593==     in use at exit: 9,502 bytes in 155 blocks
==4593==   total heap usage: 19,411 allocs, 19,256 frees, 75,240,165 bytes allocated
==4593==
==4593== 1,129 bytes in 23 blocks are definitely lost in loss record 1 of 3
==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)
==4593==    by 0x15CC36: directives (parser.c:710)
==4593==    by 0x16A548: process_term (parser.c:3063)
==4593==    by 0x16B468: tokenize (parser.c:3230)
==4593==    by 0x155612: load_text (module.c:1318)
==4593==    by 0x15B0A3: do_use_module_1 (parser.c:448)
==4593==    by 0x15B803: do_use_module_2 (parser.c:524)
==4593==    by 0x15E7BF: directives (parser.c:961)
==4593==    by 0x16A548: process_term (parser.c:3063)
==4593==    by 0x16B468: tokenize (parser.c:3230)
==4593==    by 0x155612: load_text (module.c:1318)
==4593==
==4593== 1,176 bytes in 5 blocks are definitely lost in loss record 2 of 3
==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4593==    by 0x158928: slicedup (parser.c:22)
==4593==    by 0x15CB6C: directives (parser.c:700)
==4593==    by 0x16A548: process_term (parser.c:3063)
==4593==    by 0x16B468: tokenize (parser.c:3230)
==4593==    by 0x155612: load_text (module.c:1318)
==4593==    by 0x1C755C: pl_create (prolog.c:634)
==4593==    by 0x115CD5: main (tpl.c:171)
==4593==
==4593== 7,197 bytes in 127 blocks are definitely lost in loss record 3 of 3
==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)
==4593==    by 0x15CC36: directives (parser.c:710)
==4593==    by 0x16A548: process_term (parser.c:3063)
==4593==    by 0x16B468: tokenize (parser.c:3230)
==4593==    by 0x155612: load_text (module.c:1318)
==4593==    by 0x1C755C: pl_create (prolog.c:634)
==4593==    by 0x115CD5: main (tpl.c:171)
==4593==
==4593== LEAK SUMMARY:
==4593==    definitely lost: 9,502 bytes in 155 blocks
==4593==    indirectly lost: 0 bytes in 0 blocks
==4593==      possibly lost: 0 bytes in 0 blocks
==4593==    still reachable: 0 bytes in 0 blocks
==4593==         suppressed: 0 bytes in 0 blocks
==4593==
==4593== For lists of detected and suppressed errors, rerun with: -s
==4593== ERROR SUMMARY: 22 errors from 7 contexts (suppressed: 0 from 0)

The debug print msgs are this:
$ git diff
diff --git a/src/print.c b/src/print.c
index 805ea448..61b561d6 100644
--- a/src/print.c
+++ b/src/print.c
@@ -53,6 +53,7 @@ char *chars_list_to_string(query *q, cell *p_chars, pl_idx_t p_chars_ctx, size_t
                        const char *p = C_STR(q, h);
                        int ch = peek_char_utf8(p);
                        dst += put_char_utf8(dst, ch);
+                       printf("cl2s put offset=%ld len=%ld: %c\n", (dst-tmp), len, ch);
                }

                p_chars = LIST_TAIL(p_chars);
diff --git a/src/query.c b/src/query.c
index fbf44224..e8cc437b 100644
--- a/src/query.c
+++ b/src/query.c
@@ -529,7 +529,7 @@ size_t scan_is_chars_list2(query *q, cell *l, pl_idx_t l_ctx, bool allow_codes,
                                is_chars_list = 0;
                                return 0;
                        }
-
+                       printf("inc len: %ld (src = %s)\n", len, src);
                        is_chars_list += len;
                }

Pushed a change to to devel for you to try.
On Thu, Feb 9, 2023 at 2:20 PM guregu @.***> wrote:

Seems like scan_is_chars_list2 only counts the length of the first string
'chunk' after append/3, causing chars_list_to_string to overflow.
Sample program:
leak(String) :-
append("/abc/", String, Dir),
directory_files(Dir, Files),
write(Dir),
write(Files).
Valgrind report:
$ valgrind --leak-check=full tpl test.pl -g 'trace, leak("qwertyioup"), halt'==4593== Memcheck, a memory error detector==4593== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==4593== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info==4593== Command: tpl test.pl -g trace,\ leak("qwertyioup"),\ halt==4593==[user:1:f0:fp:1:cp0:sp0:hp0:tp0] EXIT trace[user:3:f0:fp:1:cp0:sp0:hp0:tp0] CALL leak("qwertyioup")[user:5:f1:fp:2:cp0:sp3:hp0:tp0] CALL append("/abc/","qwertyioup",_1)[lists:7:f7:fp:8:cp0:sp24:hp0:tp0] EXIT append([],"qwertyioup","qwertyioup")inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)[user:9:f1:fp:8:cp0:sp24:hp0:tp0] CALL directory_files("/abc/qwert...",_2)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)cl2s put offset=1 len=5: /cl2s put offset=2 len=5: acl2s put offset=3 len=5: bcl2s put offset=4 len=5: ccl2s put offset=5 len=5: /cl2s put offset=6 len=5: q==4593== Invalid write of size 1==4593==    at 0x2189F8: put_char_utf8 (utf8.c:142)==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==cl2s put offset=7 len=5: w==4593== Invalid write of size 1==4593==    at 0x218838: put_char_bare_utf8 (utf8.c:107)==4593==    by 0x2189E7: put_char_utf8 (utf8.c:141)==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==cl2s put offset=8 len=5: ecl2s put offset=9 len=5: rcl2s put offset=10 len=5: tcl2s put offset=11 len=5: ycl2s put offset=12 len=5: icl2s put offset=13 len=5: ocl2s put offset=14 len=5: ucl2s put offset=15 len=5: p==4593== Invalid write of size 1==4593==    at 0x1BA48A: chars_list_to_string (print.c:64)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa18f is 8 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593====4593== Syscall param stat(file_name) points to unaddressable byte(s)==4593==    at 0x4E874BA: _xstat (xstat.c:35)==4593==    by 0x201E58: fn_directory_files_2 (streams.c:5500)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)   error(existence_error(directory,"/abc/qwertyioup"),directory_files/2).==4593====4593== HEAP SUMMARY:==4593==     in use at exit: 9,502 bytes in 155 blocks==4593==   total heap usage: 19,411 allocs, 19,256 frees, 75,240,165 bytes allocated==4593====4593== 1,129 bytes in 23 blocks are definitely lost in loss record 1 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)==4593==    by 0x15CC36: directives (parser.c:710)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x15B0A3: do_use_module_1 (parser.c:448)==4593==    by 0x15B803: do_use_module_2 (parser.c:524)==4593==    by 0x15E7BF: directives (parser.c:961)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593====4593== 1,176 bytes in 5 blocks are definitely lost in loss record 2 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x158928: slicedup (parser.c:22)==4593==    by 0x15CB6C: directives (parser.c:700)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x1C755C: pl_create (prolog.c:634)==4593==    by 0x115CD5: main (tpl.c:171)==4593====4593== 7,197 bytes in 127 blocks are definitely lost in loss record 3 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)==4593==    by 0x15CC36: directives (parser.c:710)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x1C755C: pl_create (prolog.c:634)==4593==    by 0x115CD5: main (tpl.c:171)==4593====4593== LEAK SUMMARY:==4593==    definitely lost: 9,502 bytes in 155 blocks==4593==    indirectly lost: 0 bytes in 0 blocks==4593==      possibly lost: 0 bytes in 0 blocks==4593==    still reachable: 0 bytes in 0 blocks==4593==         suppressed: 0 bytes in 0 blocks==4593====4593== For lists of detected and suppressed errors, rerun with: -s==4593== ERROR SUMMARY: 22 errors from 7 contexts (suppressed: 0 from 0)
The debug print msgs are this:
$ git diffdiff --git a/src/print.c b/src/print.c
index 805ea448..61b561d6 100644--- a/src/print.c+++ b/src/print.c@@ -53,6 +53,7 @@ char *chars_list_to_string(query *q, cell *p_chars, pl_idx_t p_chars_ctx, size_t
const char *p = C_STR(q, h);
int ch = peek_char_utf8(p);
dst += put_char_utf8(dst, ch);+                       printf("cl2s put offset=%ld len=%ld: %c\n", (dst-tmp), len, ch);
}
            p_chars = LIST_TAIL(p_chars);diff --git a/src/query.c b/src/query.c

index fbf44224..e8cc437b 100644--- a/src/query.c+++ b/src/query.c@@ -529,7 +529,7 @@ size_t scan_is_chars_list2(query *q, cell *l, pl_idx_t l_ctx, bool allow_codes,
is_chars_list = 0;
return 0;
}-+                       printf("inc len: %ld (src = %s)\n", len, src);
is_chars_list += len;
}
—
Reply to this email directly, view it on GitHub
https://github.com/trealla-prolog/trealla/issues/115, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNKSETLBOQZGNYEVXQ2J5LWWRWA5ANCNFSM6AAAAAAUWB3UZM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Ahh, scratch that. Problems.
On Thu, Feb 9, 2023 at 2:20 PM guregu @.***> wrote:

Seems like scan_is_chars_list2 only counts the length of the first string
'chunk' after append/3, causing chars_list_to_string to overflow.
Sample program:
leak(String) :-
append("/abc/", String, Dir),
directory_files(Dir, Files),
write(Dir),
write(Files).
Valgrind report:
$ valgrind --leak-check=full tpl test.pl -g 'trace, leak("qwertyioup"), halt'==4593== Memcheck, a memory error detector==4593== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==4593== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info==4593== Command: tpl test.pl -g trace,\ leak("qwertyioup"),\ halt==4593==[user:1:f0:fp:1:cp0:sp0:hp0:tp0] EXIT trace[user:3:f0:fp:1:cp0:sp0:hp0:tp0] CALL leak("qwertyioup")[user:5:f1:fp:2:cp0:sp3:hp0:tp0] CALL append("/abc/","qwertyioup",_1)[lists:7:f7:fp:8:cp0:sp24:hp0:tp0] EXIT append([],"qwertyioup","qwertyioup")inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)[user:9:f1:fp:8:cp0:sp24:hp0:tp0] CALL directory_files("/abc/qwert...",_2)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)cl2s put offset=1 len=5: /cl2s put offset=2 len=5: acl2s put offset=3 len=5: bcl2s put offset=4 len=5: ccl2s put offset=5 len=5: /cl2s put offset=6 len=5: q==4593== Invalid write of size 1==4593==    at 0x2189F8: put_char_utf8 (utf8.c:142)==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==cl2s put offset=7 len=5: w==4593== Invalid write of size 1==4593==    at 0x218838: put_char_bare_utf8 (utf8.c:107)==4593==    by 0x2189E7: put_char_utf8 (utf8.c:141)==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==cl2s put offset=8 len=5: ecl2s put offset=9 len=5: rcl2s put offset=10 len=5: tcl2s put offset=11 len=5: ycl2s put offset=12 len=5: icl2s put offset=13 len=5: ocl2s put offset=14 len=5: ucl2s put offset=15 len=5: p==4593== Invalid write of size 1==4593==    at 0x1BA48A: chars_list_to_string (print.c:64)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa18f is 8 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593====4593== Syscall param stat(file_name) points to unaddressable byte(s)==4593==    at 0x4E874BA: _xstat (xstat.c:35)==4593==    by 0x201E58: fn_directory_files_2 (streams.c:5500)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)   error(existence_error(directory,"/abc/qwertyioup"),directory_files/2).==4593====4593== HEAP SUMMARY:==4593==     in use at exit: 9,502 bytes in 155 blocks==4593==   total heap usage: 19,411 allocs, 19,256 frees, 75,240,165 bytes allocated==4593====4593== 1,129 bytes in 23 blocks are definitely lost in loss record 1 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)==4593==    by 0x15CC36: directives (parser.c:710)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x15B0A3: do_use_module_1 (parser.c:448)==4593==    by 0x15B803: do_use_module_2 (parser.c:524)==4593==    by 0x15E7BF: directives (parser.c:961)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593====4593== 1,176 bytes in 5 blocks are definitely lost in loss record 2 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x158928: slicedup (parser.c:22)==4593==    by 0x15CB6C: directives (parser.c:700)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x1C755C: pl_create (prolog.c:634)==4593==    by 0x115CD5: main (tpl.c:171)==4593====4593== 7,197 bytes in 127 blocks are definitely lost in loss record 3 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)==4593==    by 0x15CC36: directives (parser.c:710)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x1C755C: pl_create (prolog.c:634)==4593==    by 0x115CD5: main (tpl.c:171)==4593====4593== LEAK SUMMARY:==4593==    definitely lost: 9,502 bytes in 155 blocks==4593==    indirectly lost: 0 bytes in 0 blocks==4593==      possibly lost: 0 bytes in 0 blocks==4593==    still reachable: 0 bytes in 0 blocks==4593==         suppressed: 0 bytes in 0 blocks==4593====4593== For lists of detected and suppressed errors, rerun with: -s==4593== ERROR SUMMARY: 22 errors from 7 contexts (suppressed: 0 from 0)
The debug print msgs are this:
$ git diffdiff --git a/src/print.c b/src/print.c
index 805ea448..61b561d6 100644--- a/src/print.c+++ b/src/print.c@@ -53,6 +53,7 @@ char *chars_list_to_string(query *q, cell *p_chars, pl_idx_t p_chars_ctx, size_t
const char *p = C_STR(q, h);
int ch = peek_char_utf8(p);
dst += put_char_utf8(dst, ch);+                       printf("cl2s put offset=%ld len=%ld: %c\n", (dst-tmp), len, ch);
}
            p_chars = LIST_TAIL(p_chars);diff --git a/src/query.c b/src/query.c

index fbf44224..e8cc437b 100644--- a/src/query.c+++ b/src/query.c@@ -529,7 +529,7 @@ size_t scan_is_chars_list2(query *q, cell *l, pl_idx_t l_ctx, bool allow_codes,
is_chars_list = 0;
return 0;
}-+                       printf("inc len: %ld (src = %s)\n", len, src);
is_chars_list += len;
}
—
Reply to this email directly, view it on GitHub
https://github.com/trealla-prolog/trealla/issues/115, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNKSETLBOQZGNYEVXQ2J5LWWRWA5ANCNFSM6AAAAAAUWB3UZM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

ok, try now, in devel.
On Thu, Feb 9, 2023 at 2:20 PM guregu @.***> wrote:

Seems like scan_is_chars_list2 only counts the length of the first string
'chunk' after append/3, causing chars_list_to_string to overflow.
Sample program:
leak(String) :-
append("/abc/", String, Dir),
directory_files(Dir, Files),
write(Dir),
write(Files).
Valgrind report:
$ valgrind --leak-check=full tpl test.pl -g 'trace, leak("qwertyioup"), halt'==4593== Memcheck, a memory error detector==4593== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==4593== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info==4593== Command: tpl test.pl -g trace,\ leak("qwertyioup"),\ halt==4593==[user:1:f0:fp:1:cp0:sp0:hp0:tp0] EXIT trace[user:3:f0:fp:1:cp0:sp0:hp0:tp0] CALL leak("qwertyioup")[user:5:f1:fp:2:cp0:sp3:hp0:tp0] CALL append("/abc/","qwertyioup",_1)[lists:7:f7:fp:8:cp0:sp24:hp0:tp0] EXIT append([],"qwertyioup","qwertyioup")inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)[user:9:f1:fp:8:cp0:sp24:hp0:tp0] CALL directory_files("/abc/qwert...",_2)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)cl2s put offset=1 len=5: /cl2s put offset=2 len=5: acl2s put offset=3 len=5: bcl2s put offset=4 len=5: ccl2s put offset=5 len=5: /cl2s put offset=6 len=5: q==4593== Invalid write of size 1==4593==    at 0x2189F8: put_char_utf8 (utf8.c:142)==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==cl2s put offset=7 len=5: w==4593== Invalid write of size 1==4593==    at 0x218838: put_char_bare_utf8 (utf8.c:107)==4593==    by 0x2189E7: put_char_utf8 (utf8.c:141)==4593==    by 0x1BA3A4: chars_list_to_string (print.c:55)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==cl2s put offset=8 len=5: ecl2s put offset=9 len=5: rcl2s put offset=10 len=5: tcl2s put offset=11 len=5: ycl2s put offset=12 len=5: icl2s put offset=13 len=5: ocl2s put offset=14 len=5: ucl2s put offset=15 len=5: p==4593== Invalid write of size 1==4593==    at 0x1BA48A: chars_list_to_string (print.c:64)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa18f is 8 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593====4593== Syscall param stat(file_name) points to unaddressable byte(s)==4593==    at 0x4E874BA: _xstat (xstat.c:35)==4593==    by 0x201E58: fn_directory_files_2 (streams.c:5500)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==  Address 0x6bfa187 is 0 bytes after a block of size 7 alloc'd==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1BA1F7: chars_list_to_string (print.c:39)==4593==    by 0x201C56: fn_directory_files_2 (streams.c:5494)==4593==    by 0x1CE7B7: start (query.c:1725)==4593==    by 0x1CF010: execute (query.c:1921)==4593==    by 0x16EDA0: run (parser.c:3801)==4593==    by 0x1C5208: pl_eval (prolog.c:127)==4593==    by 0x11657E: main (tpl.c:280)==4593==inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)inc len: 1 (src = /)inc len: 1 (src = a)inc len: 1 (src = b)inc len: 1 (src = c)inc len: 1 (src = /)   error(existence_error(directory,"/abc/qwertyioup"),directory_files/2).==4593====4593== HEAP SUMMARY:==4593==     in use at exit: 9,502 bytes in 155 blocks==4593==   total heap usage: 19,411 allocs, 19,256 frees, 75,240,165 bytes allocated==4593====4593== 1,129 bytes in 23 blocks are definitely lost in loss record 1 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)==4593==    by 0x15CC36: directives (parser.c:710)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x15B0A3: do_use_module_1 (parser.c:448)==4593==    by 0x15B803: do_use_module_2 (parser.c:524)==4593==    by 0x15E7BF: directives (parser.c:961)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593====4593== 1,176 bytes in 5 blocks are definitely lost in loss record 2 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x158928: slicedup (parser.c:22)==4593==    by 0x15CB6C: directives (parser.c:700)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x1C755C: pl_create (prolog.c:634)==4593==    by 0x115CD5: main (tpl.c:171)==4593====4593== 7,197 bytes in 127 blocks are definitely lost in loss record 3 of 3==4593==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)==4593==    by 0x1C448A: print_term_to_strbuf (print.c:1434)==4593==    by 0x15CC36: directives (parser.c:710)==4593==    by 0x16A548: process_term (parser.c:3063)==4593==    by 0x16B468: tokenize (parser.c:3230)==4593==    by 0x155612: load_text (module.c:1318)==4593==    by 0x1C755C: pl_create (prolog.c:634)==4593==    by 0x115CD5: main (tpl.c:171)==4593====4593== LEAK SUMMARY:==4593==    definitely lost: 9,502 bytes in 155 blocks==4593==    indirectly lost: 0 bytes in 0 blocks==4593==      possibly lost: 0 bytes in 0 blocks==4593==    still reachable: 0 bytes in 0 blocks==4593==         suppressed: 0 bytes in 0 blocks==4593====4593== For lists of detected and suppressed errors, rerun with: -s==4593== ERROR SUMMARY: 22 errors from 7 contexts (suppressed: 0 from 0)
The debug print msgs are this:
$ git diffdiff --git a/src/print.c b/src/print.c
index 805ea448..61b561d6 100644--- a/src/print.c+++ b/src/print.c@@ -53,6 +53,7 @@ char *chars_list_to_string(query *q, cell *p_chars, pl_idx_t p_chars_ctx, size_t
const char *p = C_STR(q, h);
int ch = peek_char_utf8(p);
dst += put_char_utf8(dst, ch);+                       printf("cl2s put offset=%ld len=%ld: %c\n", (dst-tmp), len, ch);
}
            p_chars = LIST_TAIL(p_chars);diff --git a/src/query.c b/src/query.c

index fbf44224..e8cc437b 100644--- a/src/query.c+++ b/src/query.c@@ -529,7 +529,7 @@ size_t scan_is_chars_list2(query *q, cell *l, pl_idx_t l_ctx, bool allow_codes,
is_chars_list = 0;
return 0;
}-+                       printf("inc len: %ld (src = %s)\n", len, src);
is_chars_list += len;
}
—
Reply to this email directly, view it on GitHub
https://github.com/trealla-prolog/trealla/issues/115, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNKSETLBOQZGNYEVXQ2J5LWWRWA5ANCNFSM6AAAAAAUWB3UZM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Looks good now! Everything checks out, no more overflow. Thanks!


Add proxy objects for commonly-used objects

The "user" and "team" objects in flask.g. are commonly used, and currently pulled from the database on every load.  We could create a proxy objects that contain the most commonly used attributes in the user's session, and fall back to the DB for more complex needs.

Fixed in a different route.


Hold initial conversations with selected Top 75 services and assess potential for testimonial content

Brief
By the end of this brief we should held an initial conversation with all prioritised services and assessed whether we can work with them on a testimonial.
Epic lead
Katrina
Supporting roles
Kelly, Trang
Needs awareness
The entire team
### Tasks
- [ ] https://github.com/alphagov/govuk-design-system/issues/4217
- [ ] https://github.com/alphagov/govuk-design-system/issues/4299
- [x] Recruit members of the team to join initial chat
- [x] Decide on most appropriate method for collecting information on things we want to learn about

This brief is complete.


Shell script setup.sh not POSIX compliant

While it's unclear if we necessarily need to be POSIX compliant, it seems it would be a good idea to be so, especially as the setup script currently fails on Chromebooks due to this.
The major issue I've discovered thus far is [[ vs [, although a fix is a bit more complicated than just replacing [ with [[, as the [[ adds some secret sauce, allowing easier use of certain comparators.
Initial error:
./scripts/configure_delivery.sh: 32: [[: not found
./scripts/configure_delivery.sh: 35: [[: not found
./scripts/configure_delivery.sh: 38: [[: not found
Connect your repos: https://console.cloud.google.com/cloud-build/triggers/connect?project=wildsun-emblem-ops
Once your forked emblem repo is connected, please continue by typing any key../scripts/configure_delivery.sh: 45: read: arg count
Exited [2] at line 275 ./setup.sh:

The errors at line 32, 35, and 38 denote the lack of the support for [[, more information on this here:
https://www.baeldung.com/linux/bash-single-vs-double-brackets
The error at line 45, read: arg count demonstrates another posix compliance issue, in which a variable has to be specified to receive the input, even if it's not going to be used. More on this here:
https://unix.stackexchange.com/questions/581409/error-sh-1-read-arg-count

One of the weirdest lines I came across where there was an issue was this one:
https://github.com/GoogleCloudPlatform/emblem/blob/main/scripts/configure_delivery.sh#L47
if [[ -z "${REPO_NAME}" || -z "${REPO_NAME}" ]]
Anyone have any insight into why this is a thing?
Intended replacement is if [-z "${REPO_NAME}"]

This looks like it would be helpful in this context:
https://github.com/koalaman/shellcheck

Since we recommend using Cloud shell for deploying emblem, I think we can hold off on making our shell scripts posix compliant.  I created a new issue however citing your recommendation of shellcheck #728
Thanks!!


no file diffusion_pytorch_model.bin

controlnet = ControlNetModel.from_pretrained(controlnet_path, torch_dtype=torch.float16)

File "/root/miniconda3/lib/python3.10/site-packages/huggingface_hub/utils/_validators.py", line 118, in _inner_fn
return fn(*args, **kwargs)
File "/root/miniconda3/lib/python3.10/site-packages/diffusers/models/modeling_utils.py", line 634, in from_pretrained
model_file = _get_model_file(
File "/root/miniconda3/lib/python3.10/site-packages/huggingface_hub/utils/_validators.py", line 118, in _inner_fn
return fn(*args, **kwargs)
File "/root/miniconda3/lib/python3.10/site-packages/diffusers/utils/hub_utils.py", line 262, in _get_model_file
raise EnvironmentError(
OSError: Error no file named diffusion_pytorch_model.bin found in directory ./checkpoints/ControlNetModel.

Please make sure that you have downloaded the required models successfully.

https://huggingface.co/InstantX/InstantID/tree/main/ControlNetModel, there's diffusion_pytorch_model.safetensors but no diffusion_pytorch_model.bin

Please make sure that you have downloaded the required models successfully.

In https://huggingface.co/InstantX/InstantID/tree/main/ControlNetModel, there's diffusion_pytorch_model.safetensors but no diffusion_pytorch_model.bin. Fully referenced README.md

I'm facing the same error. I tried converting it to a bin but then it throws errors relating to weights, etc.

Starting from today, I'm facing the same issue guys. Why is it trying to use the .bin instead of .safetensors ? Before it used .safetensors .

ok, I found the problem. It comes from the diffusion_pytorch_model.safetensors file, something is wrong with the file. In my case, I've downloaded it using the hub downloaded , which put the model into hugging face cache, and created a symlink , and it didn't work , as I tried to run my project with docker , which means that the symlink pointed to the directory outside from the docker.

I meet the same issue. Has anyone find quick methods to fix this?
OSError: Error no file named diffusion_pytorch_model.bin found in directory ./checkpoints/ControlNetModel.

I meet the same issue. Has anyone find quick methods to fix this?
OSError: Error no file named diffusion_pytorch_model.bin found in directory ./checkpoints/ControlNetModel.

Check your diffusion_pytorch_model.safetensors file. Check it's size and actual location.

I meet the same issue. Has anyone find quick methods to fix this?
OSError: Error no file named diffusion_pytorch_model.bin found in directory ./checkpoints/ControlNetModel.

Check your diffusion_pytorch_model.safetensors file. Check it's size and actual location.

Thanks a lot. The bug is fixed. @gagbaghdas

I meet the same issue. Has anyone find quick methods to fix this?
OSError: Error no file named diffusion_pytorch_model.bin found in directory ./checkpoints/ControlNetModel.

I meet the same error and make sure it is in correct file

Error no file named diffusion_pytorch_model.bin found in directory D:\ComfyUI\ComfyUI\models\CogVideo\CogVideoX-5b-1.5.

but how?


Problem accessing entries with custom addon

I am writing a custom addon and would like to display the entires ("bookmarks") from a collection inside of my desktop widget but having difficulty doing so.  My code (which doesn't work) is below. Any ideas?
// Add Dashboard Widget
	$app->on('admin.init', function() {

        // dashboard widgets
        $this->on("admin.dashboard.widgets", function($widgets) {
            // NOTE: THIS CALL DOES NOT WORK, I CAN GET COLLECTIONS BUT NOT ENTRIES
            $bookmarks = $this->module('collections')->collections(true)->find("bookmarks");
            $widgets[] = [
                "name"    => "bookmarks",
                "content" => $this->view("bookmarks:views/widgets/dashboard.php", compact('bookmarks')),
                "area"    => 'aside-left'
            ];
        }, 100);
    });

try
$bookmarks = $this->module('collections')->find("bookmarks");
instead of
$bookmarks = $this->module('collections')->collections(true)->find("bookmarks");
or if it doesn't work, try $bookmarks = $this->app->module('collections')->find("bookmarks");
->collections() returns the schemas (+count) and not the entries.
->find($collectionname) returns fields
Another thing...
$app->on('admin.init', function() {
    $bookmarks = $this->app->module('collections')->find('bookmarks');
    return $bookmarks;
}

works the same like
$app->on('admin.init', function() use($app) {
    $bookmarks = $app->module('collections')->find('bookmarks');
    return $bookmarks;
}


Add Author & AuthorEmail to deployment environment variables

Hi!
It'd be incredibly useful to be able to access Author and AuthorEmail as environment variables, within post deployment scripts. My specific requirement is so I can notify Raygun of deployments, https://raygun.com/documentation/product-guides/deployment-tracking/deployments-api/.
Both values are already exposed in the ChangeSet class, which is used to build the DeploymentContext. https://github.com/projectkudu/kudu/blob/91aa97089b2f4cab997883d2ce902507ddd7e0ec/Kudu.Core/Deployment/DeploymentManager.cs#L656
If the DeploymentContext had both variables, it looks like they could be added as environment variables in the ExternalCommandBuilder. https://github.com/projectkudu/kudu/blob/787c893a9336beb498252bb2f90a06a95763f9e9/Kudu.Core/Deployment/Generator/ExternalCommandBuilder.cs#L92
Is there any appetite for this? I'd do the work myself (and am happy to do so), I'm just not sure I'd be able to adequately test it without a proper environment, as we use Azure.

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service