> > @b4n now that you are returning nullptr from pixels() but you did not put a
> > check for that on the return value of every use of pixels() all you have
> > done is shift the problem. :stuck_out_tongue_winking_eye:
> Not really: at least to the C guy I am, reading 0 bytes from nullptr or 0
> Kind of like making the bitwise shift operators sometimes mean "read/write IO
> stream" :smile:
Well, at least that one basically doesn't make any sense in C with the types
involved. It's not mimicking the syntax for 99.8% identical behavior and .2%
surprise :grin:
> @b4n now that you are
@b4n now that you are returning `nullptr` from `pixels()` but you did not put a
check for that on the return value of every use of pixels() all you have done
is shift the problem. :stuck_out_tongue_winking_eye:
Now we can explain it, I suspect that it would be best to pass it to Neil to
decide
> But of course thats slower, whereas operator[] is as fast as C
Not true when distros enable debug assertions in release builds...
> reproducing syntax but with a whole other lot of constraint that only apply
> in corner cases
Kind of like making the bitwise shift operators sometimes mean "rea
> As I keep saying C++ is not C :grin:
I know, and I battle for avoiding this confusion. I just see once more that
C++ tries to be confusing for C programmers, reproducing syntax but with a
whole other lot of constraint that only apply in corner cases :grin:
Anyhow, a bad patch could be as si
@b4n, yes, but std::vector is a library type, not a builtin, which keeps track
of its size and its capacity (which is why it is possible to insert the assert,
its has size to compare to, but in C since nothing saves the size of array you
malloced no automatic assert can be inserted in an index o
@elextr sure, but my point is that in C `&pointer[0]` does *not* dereference
anything, `pointer`could be anything so long as you d'ont
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/i
@b4n, by default the C++ vector index is unchecked, but no index is legal on a
zero length vector, its UB, as the spec says about operator[] `Accessing a
nonexistent element through this operator is undefined behavior.`.
The assertions flag makes it checked, as the message you posted above says
https://github.com/openscad/openscad/issues/2965#issuecomment-500542956
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-739878064
IIRC the other issue when `-D_GLIBCXX_ASSERTIONS` caused a crash, it was caused
by accessing `zero_length_vector[0]`. Let me try to find it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plug
@elextr for the moment your hint doesn't make much sense to me, you're just
point out that a 0×H image will have 0 bytes of data, which makes sense. I
don't see how it would account for accessing past the buffer, as the given size
is 0 in one direction. Well, of course the can be a bug some ot
@hroncok what that flag does is to make illegal indexing of vectors crash
rather than be ignored, so Fedora using it is why your Geany crashes but others
do not, but its not why the index was out of range in the first place.
--
You are receiving this because you are subscribed to this thread.
R
> Without testing further, my money would go on `-D_GLIBCXX_ASSERTIONS`.
I recall seeing this in other places as well, so I concur this is the flag.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/ge
@b4n
[hint](https://github.com/geany/geany-plugins/issues/1041#issuecomment-737609085)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-739857553
@elextr that's the next step, but I bet you can now debug it yourself as well
:wink: :wink: :wink:
I'll try and look at it maybe this evening if I find time.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.co
@b4n neat, so now _why_ is the access to the vector out of range?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-739851825
> FTR the cflags in Fedora are:
> […]
> And ldflags:
Ah-ah! We got a winner. If I build Geany with those flags (minus the `-spec`
parameters that obviously don't work on my Debian):
```shell
$ export LDFLAGS="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now"
$ export CFLAGS="-O2 -flto=auto -ffat-lto-ob
> > @hroncok what happens if there is no snowman in sight, but you have a space
> > character followed by the code point FE0F (which you can enter as
> > u all at once and you get a funny u then fe0f and ).
> A crash.
Ok, so the snowman has melted out of the problem, it seems to be (at least)
> FWIW I just tried to compile Geany master with Clang as well as with [what
> seem to be Fedora's hardening
> flags](https://fedoraproject.org/wiki/Changes/Harden_All_Packages), yet I
> still can't reproduce.
FTR the cflags in Fedora are:
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -
@hroncok what happens if there is no snowman in sight, but you have a space
character followed by the code point FE0F (which you can enter as
`u` all at once and you get a funny `u` then `fe0f` and ``).
--
You are receiving this because you are subscribed to this thread.
Reply to this email dir
FWIW I just tried to compile Geany master with Clang as well as with [what seem
to be Fedora's hardening
flags](https://fedoraproject.org/wiki/Changes/Harden_All_Packages), yet I still
can't reproduce.
I also tried to run in Valgrind's memcheck in case it was a memory access error
that was simp
> So, the colored variant seems not relevant for the crash.
Agree, it seems unlikely that it's related to the font, but @hroncok does have
a different emoji font than Noto.
> Can I run it without make install? Do I need to do this with plugins and
> geany somehow combined?
You could configure
Can I run it without make install? Do I need to do this with plugins and geany
somehow combined?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-739417346
> > Also, my snowman is always in the uncolored variant
>
> To copy into Geany, I had to "Edit" this issue description and copy/paste
> from there (and then cancel the edit). I think you also need a fallback font
> that provides it to be installed like [Noto Color
> Emoji](https://www.google.co
```
$ fc-match -s monospace | grep -i emoji
OpenSansEmoji.ttf: "OpenSansEmoji" "Regular"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plug
Here:
```bash
$ fc-match -s monospace | grep -i emoji
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-73922
> I kinda think that having the colored version is a must for the crash to
> happen :/
Perhaps, but not the sole requirement, @codebrainz has the coloured snowman,
and no crash
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHu
> I don't have the "DejaVu Sans Mono Regular" font variant
Me either
> Also, my snowman is always in the uncolored variant
To copy into Geany, I had to "Edit" this issue description and copy/paste from
there (and then cancel the edit). I think you also need a fallback font that
provides it to
I kinda think that having the colored version is a must for the crash to happen
:/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-739218929
I don't have the "DejaVu Sans Mono Regular" font variant :(.
Also, my snowman is always in the uncolored variant, even when not "split":
Not sure why this is. Still, no matter wha
> The snowman code point is followed by a variant selector code point that says
> make the preceding character a different style, in the case of the snowman it
> makes it coloured. Your "split" puts another code point between the snowman
> and the variant selector so it applies to this code poin
@hroncok I don't think the snowman matters, @eht16 will be pleased to know that
you are not actually splitting the snowman :grin:. The snowman code point is
followed by a variant selector code point that says make the preceding
character a different style, in the case of the snowman it makes it
```
$ fc-match Monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Regular"
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-737707422
Got it!!! When creating the XPM image of the squiggle to underline the spelling
error Scintilla allocates a vector to hold it whose size is `width*height*4`
and that doesn't allocate if the width or height is zero, so any index
operation will likely crash.
Unfortunately the backtrace @hroncok
In my test I was using same font as @eht16 except size 10, but I believe
emojies fallback to some of the Noto* fonts, one for the black and white and a
different one for the colour emoji.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view i
Note that I agree with @eht16 that its likely an error in the length
calculation of the indicator, possibly due to rounding of Font data to integer
(thats happened elsewhere IIRC, and a "fix" added) but quite why that manifests
itself as accessing a vector at an illegal location I'm not sure. B
> Goodness @eht16 your Arch is 0.0.1 behind on Glib, I thought Arch was totally
> bleeding edge grin
Arch is totally bleeding egde as you'D expect it
(https://www.archlinux.org/packages/core/x86_64/glib2/), just my local system
isn't so much because of my personal lazyness :).
> Its still pos
Goodness @eht16 your Arch is 0.0.1 behind on Glib, I thought Arch was totally
bleeding edge :grin:
Anyway thats unlikely to be the difference.
Its still possibly the font, @hroncok you said "monospace", but thats usually
an alias for something else, can you find what or specify the other one
I'm using DejaVu Sans Mono Book 8 with
```
23:24:25: Geany INFO: Geany 1.38 (git >= 00ca7e7a), en_US.utf8
23:24:25: Geany INFO: GTK 3.24.23, GLib 2.66.2
23:24:25: Geany INFO: OS: Arch Linux
```
Pango: 1.48.0-1
--
You are receiving this because you are subscribe
Probably Scintilla (or Pango) has problems with ignoring variation sequences if
the preceeding character isn't variable.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issu
When I split a snowman I get this:
No crashes.
```
18:20:05: Geany INFO: Geany 1.38 (git >= d2740f21f), en_CA.UTF-8
18:20:05: Geany INFO: GTK 3.24.20, GLib 2.64
Changing font to a random different font doesn't make a difference.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-736168085
> post the version of GTK and Glib and OS and version (see top of help->debug
> messages)
Using GTK+ v3.24.23 and GLib v2.66.3 runtime libraries
```
02:58:18: Geany INFO: Geany 1.37.1, cs_CZ.utf8
02:58:18: Geany INFO: GTK 3.24.23, GLib 2.66.3
02:58:18: Geany INFO
>From the various issues on spellcheck it seems that Scintilla has a problem
>drawing indicators on damaged or zero width characters.
The fact that @eht16 can't reproduce suggests its also font and/or Pango
version dependent. @hroncok as I keep saying, post the version of GTK and Glib
and OS
Don't split snowmen!!! How dare you?
More seriously, the difference to #1022 and #1036 is that @hroncok seems to be
using 1.37 and not 1.36.
The backtrace shows the more or less obvious: the crash seems to happen while
drawing the indicator in Scintilla. It might be there is a bug in the start t
> I see no patch that could possibly affect this. @dmaphy can confirm or deny.
Confirmed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-736070305
```
[New Thread 0x75822640 (LWP 2038263)]
[New Thread 0x74f8b640 (LWP 2038264)]
[New Thread 0x7fffe7fff640 (LWP 2038265)]
[New Thread 0x7fffe77fe640 (LWP 2038266)]
[Detaching after fork from child process 2038267]
[Thread 0x7fffe77fe640 (LWP 2038266) exited]
/usr/include/c++/10/bits/stl_vec
I see no patch that could possibly affect this. @dmaphy can confirm or deny.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-735949748
Sounds like #1022 (and #1036). We didn't *really* figure out what's happening
because on #1022 the user didn't see the problem after manually rebuilding the
package, which doesn't make much sense -- unless Fedora has a broken patch?
--
You are receiving this because you are subscribed to this
Thanks @elextr, I've only realized this is dependent on spell check when
creating the screenshot.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1041#issuecomment-735705602
Hello. I run geany 1.37.1 on Fedora 33 and Geany crashes when I try to put a
space between an emoji and Unicode VARIATION SELECTOR-16.
Steps to reproduce:
1. Enable the Spell Check plugin and enable spell checking. I use en_US in case
it matters.
2. Insert an emoji with VARIATION SELECTOR-16, e
51 matches
Mail list logo
