wine-bugs February 2022

wine-bugs@winehq.org

1 participants
3940 discussions

[Bug 39379] New: test.winehq.org: Show a specific test history for a machine or platform
by wine-bugs＠winehq.org 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=39379 Bug ID: 39379 Summary: test.winehq.org: Show a specific test history for a machine or platform Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Currently it's possible to see at a glance how specific test fared across Wine commits and *all platforms*. For instance: https://test.winehq.org/data/tests/advapi32:service.html But if a platform has multiple test machines, one where the test has always failed and another where it has just started failing, one cannot see when the failures started on the above page. So it would be nice to have a similar page on a per-platform basis; or one with all the reports where that test failed regardless of platform. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 4

[Bug 48164] New: test.winehq.org should provide an efficient way to detect new failures
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=48164 Bug ID: 48164 Summary: test.winehq.org should provide an efficient way to detect new failures Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Problem ------- test.winehq.org does not allow performing the following tasks efficiently: 1. Detecting when a new failure slips past the TestBot. One can detect new failures on the per test unit page when specific columns turn red. But quite often the test unit already has failures so one has to look at the specific number of failures. Furthermore many test units currently have failures so this requires checking 80+ pages individually. 2. Detecting when the results on a VM degrade. After upgrading a machine it's useful to compare it to its previous results. But the results for each date are on separate pages. So again it's necessary to check the per-test-unit result pages. 3. Comparing the results of two machines of different platforms. For instance comparing the results of running Windows 8 to those of Windows 10 on the same hardware. Other things that got asked: 4. Sometimes it would be nice to have only the failures, and not all the lines with skipped tests and todos. 5. In some cases it would also be nice to have pages with only the failures that happen on TesBot VMs since these are usually easier to reproduce. Jeremy's page ------------- Jeremy's test summary page can help with some of that: https://www.winehq.org/~jwhite/latest.html But: * It's not integrated with test.winehq.org which makes it hard to find. * There are only two states: Success and Failed: So it does not help when a test goes from having 2 failures to 4, or when it has a set of systematic failures and a set of intermittent ones. * The failed / success pattern is not per VM which masks some patterns and does not help with point 2. Proposal -------- A modified version of Jeremy's page could be integrated with test.wnehq.org: * It would actually be a pair of 'Failures' pages, one for TestBot VMs and one for all test results. Both would be linked to from the top of the main index page, for instance using the same type of 'prev | next' text links used on the other pages. * Jeremy's result matrix would be extended from three to four dimensions; test units, test results, time, and number/type of failures. * As before the results would be grouped per test unit in alphabetical order. Only the test units having at least one error, recent or not, would be shown. This could again be in the form of an array ('full report' pages on test.winehq.org) or simply test unit titles (TestBot jobDetails page style) with the information about each test unit inside. Clicking on the test unit name would link to its 'test runs' page on test.winehq.org. * For each test unit there would be one line per test result having errors. The first part of the line would have one character per commit for the whole history available on test.winehq.org. That character would indicate if the test failed and more. The second part of the line would be the test result platform and tag. They would be sorted per platform and alphabetically. * Each test result would get a one character code: . Success F Failure C Crash T Timeout m Missing dll (foo=missing or other error code) e Other dll error (foo=load error 1359 and equivalent) _ No test (the test did not exist) ' ' No result (the machine did not run the tests that day) * These codes would be shown using a monospace font so they would form a pattern across time and test results: .....F..F...F..F.mmm Win8 vm1 .....FFFFeFFFFFFeFFF Win8 vm1-ja ...TTCC Win8 vm2-new ......eF...F...F..F. Win10 vm3 * Each character would have a tooltip containing details like the meaning of the letter, the number of failures, or the dll error message. They would also link to the corresponding section of the test report. * In addition to the character the background would be color coded to make patterns more visible. . Green F Green to yellow to red gradient C Dark red T Purple/pink m Cyan e Dark blue _ Light gray ' ' White * The green-yellow-red gradient would be what allows detecting changes in the number of test failures. That gradient must be consistent for all lines of a given test unit's pattern. Furthermore the gradient must not be computed based on the test result's number of failures. That is, if a test unit has either 100 or 101 failures, those must not have nearly indistinguishable colors. Instead the set of all different failure counts for the test unit should be collected. Zero should be added to that set. Then these values should be sorted and a color attributed for each *index*. Then the background color is selected based on the index of that result's failures count. It is expected that each set will be relatively small so that the colors will be reasonably far apart, making it easy to distinguish a shift from 4 to 6 failures even if there are 100 failures from time to time. Also note hat adding zero to the set essentially reserves green for successful results. Implementation feasibility -------------------------- * No changes in dissect. * In gather, generate a new testunits.txt file containing one line per test unit: - The data source would be the per-report summary.txt files. -> These don't indicate when a timeout has occurred so timeouts will appear as F instead which is acceptable for a first implementation. - The first line would contain a star followed by the tags of all the test runs used to build the file: - The other lines would contain the name of the test unit followed by space-separated pairs of result code/failure count and result tag (including the platform). - A line would be put out even if the test unit had no failure. For instance, the commit1 testunit.txt file could contain: * win8_vm1 win8_vm1-ja win8_vm2-new win10_vm3 foo:bar 43 win8_vm1-ja C win8_vm2-new e win10_vm3 foo:bar2 - In the example above win8_vm1 only appears on the first line. This means WineTest was run on that machine but had no failure at all. - If the results for commit2 refer to a win8_vm4 machine, we will know that the reason win8_vm4 does not appear in commit1 file is not because all the tests succeeded, but because WineTest was not run on win8_vm4 for commit1. This means that the result code for win8_vm4 for commit1 should be ' '. not '.' for all test units. - If commit2 has results for the foo:bar3 test unit, then we will know the reason it is not present in the commit1 file is not because all the test runs were successful, but because foo:bar3 did not exist yet. So its result code would be '_', not '.'. * Add a new build-failures script to generate both failures pages. - This script will need to read the testunits.txt file for all the commits. The simplest implementation will be to read all the data into memory before generating the page. This will avoid having to deal with keeping the current test unit synchronized between all of the testunits.txt files when a new test unit has been added. - The combined size of the testunits.txt files is expected to be reasonable, within a factor of 3 of the summary.txt files. For reference, here is some data about the sizes involved: $ du -sh data 21G data $ ls data/*/*/report | wc -l 2299 $ cat data/*/*/report | wc 34,087,987 231,694,407 2,104,860,095 $ cat data/*/*/report | egrep '(: Test failed:|: Test succeeded inside todo block:|done [(]258)|Unhandled exception:)' | wc 567,158 6,275,504 53,202,999 $ cat data/*/summary.txt | wc 186,219 3,046,363 30,596,901 - Having a function to generate the page will allow calling it twice in a row to generate both pages without having to load and parse the testunits.txt files twice. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 51352] New: test.winehq.org should distinguish "too much data" errors from others
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=51352 Bug ID: 51352 Summary: test.winehq.org should distinguish "too much data" errors from others Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The new patterns page treats the "test printed too much data" failures like any other. It would be better to use another symbol and color when there is no other failure. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 49058] New: https://source.winehq.org/git/website.git/ directs users to clone from http://, not https://
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=49058 Bug ID: 49058 Summary: https://source.winehq.org/git/website.git/ directs users to clone from http://, not https:// Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: --- austin@laptop /tmp $ git clone http://source.winehq.org/git/wine.git Cloning into 'wine'... warning: redirecting to https://source.winehq.org/git/wine.git/ Looks like this is in the website config: https://source.winehq.org/git/website.git/blob/dccd8b12e3bce9d7a9cc2112e511… note, applies to the other git repos as well. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 52088] New: Update favicon to 32X32
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=52088 Bug ID: 52088 Summary: Update favicon to 32X32 Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: 2ndforwine(a)inmano.com Distribution: --- The 16x16 looks very blurry when compared to other web-sites. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 50630] New: Old link on https://www.winehq.org/news
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=50630 Bug ID: 50630 Summary: Old link on https://www.winehq.org/news Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: jkfloris(a)dds.nl Distribution: --- At the bottom of the page there is a link to World Wine News Archive - https://www.winehq.org/wwn The last "news" item is from 2017. Maybe it is an idea to remove this link. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 51613] New: Broken link at https://wiki.winehq.org/Developer_Hints in conformance tests section
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=51613 Bug ID: 51613 Summary: Broken link at https://wiki.winehq.org/Developer_Hints in conformance tests section Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: tatidev1454(a)protonmail.com Distribution: --- Link to http://www.winehq.org/site/docs/winedev-guide/testing broken at "writing conformance tests" section in https://wiki.winehq.org/Developer_Hints -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 50516] New: Broken link 'https://wiki.winehq.org/Useful_Registry_Keys'
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=50516 Bug ID: 50516 Summary: Broken link 'https://wiki.winehq.org/Useful_Registry_Keys' Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: jose.relland(a)free.fr Distribution: --- Hi, thank you for your time. I noted that the linnk: "Wine Man Page" (at the bottom of the page) is broken. Send to 404 page error. Best 2021 year :) José from France -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 50512] New: Wiki /Bugs links broken, can't edit them
by WineHQ Bugzilla 09 Apr '22

09 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=50512 Bug ID: 50512 Summary: Wiki /Bugs links broken, can't edit them Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: ddascalescu+wine(a)gmail.com Distribution: --- I've created an account to edit the wiki. May I please have permission to do so? I'm User:Dandv on Wikipedia as well. Due to the extensive reorg of https://wiki.winehq.org/Wine_User's_Guide, the links at https://wiki.winehq.org/Bugs in "You installed and ran the application using Wine, not on your Windows installation" are broken. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 52340] New: wine-mono + RMS Express: COM Port errors connecting to radios
by WineHQ Bugzilla 08 Apr '22

08 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=52340 Bug ID: 52340 Summary: wine-mono + RMS Express: COM Port errors connecting to radios Product: Wine Version: 7.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: eric.wheez(a)gmail.com Distribution: --- Hello again, I just wanted to report in a "not implemented" exception in wine-mono. I believe that "System.IO.Ports.SerialPort.set_ReceivedBytesThreshold" not implemented in wine-mono is causing RMS Express to not be able to control the radio (channel selection and "push-to-talk"/"PTT" switch) over USB connection. Normal behavior is for RMS Express to tell the radio what radio channel to send/receive on & when to transmit/listen (via PTT switch). This behavior is working on RMS Express via Windows. This behavior is also working with RMS Express on Debian 10 VM with wine & .NET 4.6 (I had to set `sudo adduser $USER dialout && sudo reboot` to set permissions for the COM port for the user account so before channels/PTT worked .NET 4.6 though). The not implemented exception pops up in the linux terminal with wine-mono exactly at the same time that the (known-working-with-.NET4.6) COM port is said to be inaccessible. I've included the short log of the wine-mono not implemented exception at the of this post. [Setup] OS: Debian 10 (VMware Workstation on a Windows laptop) Wine: wine-7.0-rc4 devel Wine Mono: wine-mono 2f50d2c (https://nightly.link/madewokherd/wine-mono/actions/artifacts/131614059.zip) Program: Winlink Express 1.5.44.0 Radio: Yaesu FT-891 transceiver (with dummyload attached directly to radio - no feed line so I don't accidentally send signals) Details: - FT-891 connected to PC via USB cable (and make sure VMWare has the USB line routed into the VM instead of the host PC) - I set the FT-891's on-board settings to data 'baud' 9600. - I set in/out audio devices in ARDOP settings on the PC. Thank you again! And here's to 2022 being better than the previous two years :) Cheers ---- wine-mono not implemented exception log: ``` WINE_MONO_TRACE=E:System.MissingMethodException MONO_INLINELIMIT=0 WINE_MONO_HIDETYPES=1 wine RMS\ Express.exe ... [00000024:] EXCEPTION handling: System.NotImplementedException: The method or operation is not implemented. "<unnamed thread>" tid=00000024 this=04570120 , thread handle : 01df5788, state : not waiting at System.IO.Ports.SerialPort.set_ReceivedBytesThreshold (int) [0x0000f] in <117354a27af94c36af91c072a84e6fb8>:0 at (wrapper remoting-invoke-with-check) System.IO.Ports.SerialPort.set_ReceivedBytesThreshold (int) [0x00032] in <117354a27af94c36af91c072a84e6fb8>:0 at RMS_Express.Radio.OpenControlPort () [0x000b3] in <25c56d5497bc4490bd1b5395b173c5df>:0 at RMS_Express.Radio.SetRadio () [0x0014f] in <25c56d5497bc4490bd1b5395b173c5df>:0 at RMS_Express.Radio.SetFrequency (int,string) [0x00021] in <25c56d5497bc4490bd1b5395b173c5df>:0 at (wrapper remoting-invoke-with-check) RMS_Express.Radio.SetFrequency (int,string) [0x00033] in <25c56d5497bc4490bd1b5395b173c5df>:0 at RMS_Express.ArdopSession.Ardop_Activated (object,System.EventArgs) [0x00823] in <25c56d5497bc4490bd1b5395b173c5df>:0 at System.Windows.Forms.Form.OnActivated (System.EventArgs) [0x0001f] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Form.set_Active (bool) [0x000a6] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Form.WmActivate (System.Windows.Forms.Message&) [0x0001a] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message&) [0x001b8] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067> at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Windows.Forms.SafeNativeMethods.ShowWindow (System.Runtime.InteropServices.HandleRef,int) <0x00012> at System.Windows.Forms.Control.SetVisibleCore (bool) [0x00061] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Form.SetVisibleCore (bool) [0x000d1] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control.set_Visible (bool) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control.Show () [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at RMS_Express.ArdopSession.ShowSession () [0x00000] in <25c56d5497bc4490bd1b5395b173c5df>:0 at RMS_Express.Main.StartSession () [0x005fd] in <25c56d5497bc4490bd1b5395b173c5df>:0 at RMS_Express.Main.mnuSession_Click (object,System.EventArgs) [0x00000] in <25c56d5497bc4490bd1b5395b173c5df>:0 at System.Windows.Forms.ToolStripItem.RaiseEvent (object,System.EventArgs) [0x0001b] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStripMenuItem.OnClick (System.EventArgs) [0x0001d] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStripItem.HandleClick (System.EventArgs) [0x00051] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStripItem.HandleMouseUp (System.Windows.Forms.MouseEventArgs) [0x000fd] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStripItem.FireEventInteractive (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00053] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00103] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00033] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs) [0x0007d] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control.WmMouseUp (System.Windows.Forms.Message&,System.Windows.Forms.MouseButtons,int) [0x001c3] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) [0x005a0] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message&) [0x00043] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message&) [0x00128] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.MenuStrip.WndProc (System.Windows.Forms.Message&) [0x00056] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067> at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW (System.Windows.Forms.NativeMethods/MSG&) <0x00012> at System.Windows.Forms.Application/ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop (intptr,int,int) [0x001d7] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Application/ThreadContext.RunMessageLoopInner (int,System.Windows.Forms.ApplicationContext) [0x00282] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x0001a] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x00033] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) [0x00006] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0 at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun () [0x00044] in <e344caf534bf4ffb982376a141ed987b>:0 at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel () [0x00035] in <e344caf534bf4ffb982376a141ed987b>:0 at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run (string[]) [0x0001b] in <e344caf534bf4ffb982376a141ed987b>:0 at RMS_Express.My.MyApplication.Main (string[]) [0x0000f] in <25c56d5497bc4490bd1b5395b173c5df>:0 at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00027] in <25c56d5497bc4490bd1b5395b173c5df>:0 ``` -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 13

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs February 2022