Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

noWindowExample issue in latest #7781

Closed
dimitre opened this issue Dec 4, 2023 · 2 comments
Closed

noWindowExample issue in latest #7781

dimitre opened this issue Dec 4, 2023 · 2 comments
Assignees
Labels

Comments

@dimitre
Copy link
Member

dimitre commented Dec 4, 2023

noWindow example fails compiling and running use make in macOS.
cc @artificiel

/bin/sh: line 1: 27411 Segmentation fault: 11  ./noWindowExample

Crash Report

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   noWindowExample               	       0x1026f8eec std::__1::mersenne_twister_engine<unsigned int, 32ul, 624ul, 397ul, 31ul, 2567483615u, 11ul, 4294967295u, 7ul, 2636928640u, 15ul, 4022730752u, 18ul, 1812433253u>::operator()() + 0
1   noWindowExample               	       0x10271efc0 ofRandom(float) + 28
2   noWindowExample               	       0x1026adcc4 ofApp::draw() + 48
3   noWindowExample               	       0x1026ebf30 std::__1::__function::__func<std::__1::shared_ptr<of::priv::Function<ofEventArgs, std::__1::recursive_mutex>> ofEvent<ofEventArgs, std::__1::recursive_mutex>::make_function<ofBaseApp>(ofBaseApp*, void (ofBaseApp::*)(ofEventArgs&), int)::'lambda'(void const*, ofEventArgs&), std::__1::allocator<std::__1::shared_ptr<of::priv::Function<ofEventArgs, std::__1::recursive_mutex>> ofEvent<ofEventArgs, std::__1::recursive_mutex>::make_function<ofBaseApp>(ofBaseApp*, void (ofBaseApp::*)(ofEventArgs&), int)::'lambda'(void const*, ofEventArgs&)>, bool (void const*, ofEventArgs&)>::operator()(void const*&&, ofEventArgs&) + 40
4   noWindowExample               	       0x10276e968 ofEvent<ofEventArgs, std::__1::recursive_mutex>::notify(ofEventArgs&) + 156
5   noWindowExample               	       0x10276c77c ofCoreEvents::notifyDraw() + 40
6   noWindowExample               	       0x1026e9450 ofMainLoop::loopOnce() + 224
7   noWindowExample               	       0x1026e9344 ofMainLoop::loop() + 56
8   noWindowExample               	       0x1026ae434 main + 236
9   dyld                          	       0x197427f28 start + 2236

Different error in XCode:

[notice ] 1
Assertion failed: (the_instance), function instance, file ofSingleton.h, line 51.
@artificiel
Copy link
Contributor

artificiel commented Dec 4, 2023

interesting: the no-window example code for main went from:

	ofAppNoWindow window;
	ofSetupOpenGL(&window, 1024, 768, OF_WINDOW);
	ofRunApp(new ofApp());

to new flavour:

	auto window = std::make_shared<ofAppNoWindow>();
	ofRunApp(window, std::make_shared<ofApp>());
	ofRunMainLoop();

which looks logical and cleaner.

but the initialization of the new random engine is called in of::priv::initutils() which is triggered within ofInit(), which makes it more like a symptom than the actual problem: ofInit() is called by ofSetupOpenGL() — this means the new flavour does not go through ofInit().

  1. should ofInit() and/or of::priv::initutils() be called for ofAppNoWindow? (there seems to be windowing stuff in there, but also non-windowing things).
  2. if ofInit() and/or of::priv::initutils() are not to be called for ofAppNoWindow, where should the random engine initialization be situated?
  3. the OF guidelines say not to use assert — there is such a call in the original ofSingleton implementation I based ofSingleton on, and I left it because it helps tracking uninitialized instances, and as mentioned elsewhere, the favoured pattern of explicit singleton construction (as opposed to lazy initialization upon first access) removes many criticism for singleton implementations. here we see it provides good info, as the singleton is found to be uninitialized before being actually used and causing a plain memory access crash (if you want to see the crash you can try in Release which ignores assert()). anyway I just mention this as I don't have much experience with assert so I can't argue for/against , but I find this situation interesting.

TLDR: with ofAppNoWindow , ofRandomEngine() is uninitialized because it's ::construct() method situated in of::priv::initutils() does not run.

@danoli3 danoli3 added the macOS label Dec 13, 2023
@danoli3 danoli3 self-assigned this Feb 10, 2024
danoli3 added a commit to danoli3/openFrameworks that referenced this issue Feb 10, 2024
@danoli3
Copy link
Member

danoli3 commented Feb 10, 2024

Screenshot 2024-02-10 at 11 50 47 am

ofInit() in the ctor for this window type fixed it!

danoli3 added a commit to danoli3/openFrameworks that referenced this issue Feb 10, 2024
danoli3 added a commit to danoli3/openFrameworks that referenced this issue Feb 10, 2024
danoli3 added a commit to danoli3/openFrameworks that referenced this issue Mar 13, 2024
danoli3 added a commit to danoli3/openFrameworks that referenced this issue Mar 14, 2024
* branch_bleedingiOS:
  Revert "Xcode Project to XML iOS / macOS"
  Xcode Xchemas
  tvOS Update Bleeding
  Xcode Project to XML iOS / macOS
  Xcode Pbxproj to XML script - XML is required for PG to work for these projects. Added script as we keep forgetting
  Fix ofxAccelerometer / url off for tvOS
  iOS Download Libs / Actions and scripts for other platforms
  iOS curl disabled for moment
  iOS Bleeding Latest
  GitHub Actions macOS makefiles on
  GitHub Actions
  GitHub Actions - macOS disabled makefile until dupe fix
  macOS addon ofxSVG
  Apothecary on Bleeding
  Fixes openframeworks#7781
  macOS just one download latest libs
  macOS Download Libs Fix path no arch as xcframework merged
  GitHub Actions
  macOS GitHub Actions Latest Libs
  Xcode Project Updates to XCFrameworks C++17 - Bleeding Edge

# Conflicts:
#	.github/workflows/build-ios-tvos.yml
#	libs/openFrameworksCompiled/project/osx/CoreOF.xcconfig
danoli3 added a commit to danoli3/openFrameworks that referenced this issue May 16, 2024
danoli3 added a commit to danoli3/openFrameworks that referenced this issue Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants