@mflatt I am troubleshooting this issue using errortrace, but I ran into another problem with it: abuild@HMSBeagle:~/rpmbuild/BUILDROOT/racket-8.5-0.x86_64/usr/share/racket/pkgs/draw-lib/racket/draw/private> racket -l errortrace -t ../../../../drracket/gui-debugger/debug-tool.rkt identifier used out of context: #<syntax:/home/abuild/rpmbuild/BUILDROOT/racket-8.5-0.x86_64/usr/share/racket/pkgs/gui-lib/framework/private/text-port.rkt:83:17 committer?>

bascially I am trying to figure out why the cairo surface is false

This appears to be a problem with expand and #%variable-reference and rename transformer.

I’ll look at fixing the expander

thanks

I’ve pushed that repair

Is there a reason why modifying a gui canvas from multiple threads would cause the program to quit/crash without an error on windows but not macos/linux?

or maybe running a thread (even one that does nothing)?

@tgbugs Section “1.6.2. Eventspaces and Threads” has the following to say: > Windowing functions and methods from https://docs.racket-lang.org/gui/index.html\|racket/gui/base can be called in any thread, but beware of creating race conditions among the threads or with the handler thread. Graphical objects are thread-safe, but callbacks or other event handlers might see changing object states if graphical elements are manipulated in multiple threads. Editor classes have more significant thread constraints; see <https://docs.racket-lang.org/gui/editor-overview.html#%28part._editorthreads%29|Editors and Threads>.

If you are seeing a crash on Windows, it might a bug in racket/gui ?

@soegaard2 thanks, it actually seems like it isn’t threads at all

not entirely sure what it is yet, but I was able to eliminate the thread and still get the behavior, which is a relief

Try to eliminate Windows :stuck_out_tongue:

@laurent.orseau if only

Ok, so … is there a reason why calling directory-exists? or file-exists on a symlink on windows would cause a gui program to crash !?

time to go dig in the code

No exception raised?

none

Did you start the program from the command line?

@laurent.orseau happens from cli and running a gui exe

ok. Make sure you run from the cli, because if an exception is raised maybe you won’t see it (it should open a terminal window, but if the program terminates maybe the window will be close automatically depending on your Settings I think)

here is a one line repro

open racket from a terminal and run: (file-exists? "C:\\path\\to\\symlink")

and racket will crash

That certainly sounds like a bug

I’m still not 100% on that repro, it does it with some links but not others

AH HA

the links that fail are created by python, not mklink, and they are relative links “relative/path” instead of the fully resolved links that mklink creates “C:/relative/path”

but wait, there’s more! I think that the directory link has to be missing a trailing slash

which racket cannot create by itself, but apparently python can

nope, still some missing factor

length of the name of the symlink target folder

If it’s a prime number it crashes?

haha if only, no, if it is longer than 60 chars

submitting a bug now

Glad you figured out the problem at least

https://github.com/racket/racket/issues/4233

I think I have a workaround which involves resolving the path and then using build-path until the underlying issue is resolved.

er … not quite right on the numbers, it is total path length

updating

Maybe mention it in the Issue, this may help resolve it, or provide a workaround to others in the meantime?

yep will add

the magic number is 127 -> 128 chars, which is more like what I would expect for something like this, 60 seemed wrong

@mflatt is it possible to build a full racket in an environment where git_init_check returns false?

gtk_init_check? Yes, I’m pretty sure we build that way often — such as every snapshot build, which is on a Linux machine with no X display and without using something like xvfb-run.

Unless I misunderstand what you mean, this constraint is why documentation is not allowed to depend on racket/gui for rendering.

that was my experience too.

But if I comment this expression https://github.com/racket/drracket/blob/master/drracket/gui-debugger/debug-tool.rkt#L45 and the export expression above and I load this module,

I get the gtk initialization failure

if I do nothing and just simply load this module, I get an error similar to the one in the main post

what’s the magic behind all this?

I’m not sure I understand the question. Compiling code is not the same thing as running it, and there’s no problem compiling a module that has (require racket/gui). There would be a problem compiling a module that has (require (for-syntax racket/gui)) or rendering a document that performs a (require racket/gui).

I think some modules in images use racket/draw at expansion time (so, compile time). It would make sense that compilation would fail if something goes wrong in those libraries. Maybe the particular expansion-time code is triggered only when an identifier is referenced, and that would explain why the error goes away when you comment out a reference — but that’s just a guess.

I wasn’t clear. By “load”, what I meant was simply racket debug-tool.rkt or (require "debug-tool.rkt") .

I understood that much. Merely loading the module file with racket -f debug-tool.rkt would compile and declare the module and not run it. I expect you’d get the drawing-context error when merely loading, instead of the X display error.

Indeed, I get the drawing context error when I compile the module

Thanks, your comments clarify a lot of things

My further investigation shows: https://github.com/racket/images/blob/master/images-lib/images/icons/symbol.rkt#L70 the result h is very large, 1134930 but w is 20

the arguments str and font are quite normal as well

It seems that because of the unusually large height, the drawing context is not okay (i.e. (send dc ok?) => #f) . Calling draw-text on a not-okay drawing context raises the error

The underlying problem seems to relate to pango (in the method do-text of dc%, but I haven’t figured it out yet.

it looks like it has something to do with this line https://github.com/racket/draw/blob/master/draw-lib/racket/draw/private/dc.rkt#L1577

or the initialization of layout