wine-bugs February 2018

wine-bugs@winehq.org

1 participants
8047 discussions

[Bug 44606] New: Memory leak in [import.c:367]
by wine-bugs＠winehq.org 26 Feb '18

26 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=44606 Bug ID: 44606 Summary: Memory leak in [import.c:367] Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: fan.gang.cn(a)gmail.com Distribution: --- Created attachment 60594 --> https://bugs.winehq.org/attachment.cgi?id=60594 The sourcebrella-pinpoint screenshot of a memory leak defect. We find a memory leak defect in the file tools/winebuild/import.c. I've uploaded a screenshot of the leak trace. The memory stored to dll_name is not freed anywhere in this function (add_static_import_dll has not freed this memory, it allocated its own string buffer instead. ). Gang Sourcebrella -- 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 0

[Bug 44605] New: Memory leak in [main.c:688]
by wine-bugs＠winehq.org 26 Feb '18

26 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=44605 Bug ID: 44605 Summary: Memory leak in [main.c:688] Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: fan.gang.cn(a)gmail.com Distribution: --- Created attachment 60593 --> https://bugs.winehq.org/attachment.cgi?id=60593 The sourcebrella-pinpoint screenshot of a memory leak defect. We find a memory leak defect in the file tools/winebuild/main.c. I've uploaded a screenshot of the leak trace. Even though this leak happens in the main function, which means this cannot be count as an actual leak. It is still recommended to free the resource for better coding practice and for future wine newbies. Gang Sourcebrella -- 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 0

[Bug 44604] New: Memory leak in [res32.c:316][import.c:332]
by wine-bugs＠winehq.org 26 Feb '18

26 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=44604 Bug ID: 44604 Summary: Memory leak in [res32.c:316][import.c:332] Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: fan.gang.cn(a)gmail.com Distribution: --- Created attachment 60592 --> https://bugs.winehq.org/attachment.cgi?id=60592 The sourcebrella-pinpoint screenshot of a memory leak defect. We find a memory leak defect in the file tools/winebuild/import.c. I've uploaded a screenshot of the leak trace. The memory allocated by get_dll_name should be freed somewhere in this function. Gang Sourcebrella -- 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 0

[Bug 44603] New: Memory leak in [import.c:290]
by wine-bugs＠winehq.org 26 Feb '18

26 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=44603 Bug ID: 44603 Summary: Memory leak in [import.c:290] Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: fan.gang.cn(a)gmail.com Distribution: --- Created attachment 60591 --> https://bugs.winehq.org/attachment.cgi?id=60591 The sourcebrella-pinpoint screenshot of a memory leak defect. We find a memory leak defect in the file tools/winebuild/import.c. I've uploaded a screenshot of the leak trace. Gang Sourcebrella -- 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 1

[Bug 44602] New: Memory leak in [spec32.c:215]
by wine-bugs＠winehq.org 26 Feb '18

26 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=44602 Bug ID: 44602 Summary: Memory leak in [spec32.c:215] Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: fan.gang.cn(a)gmail.com Distribution: --- Created attachment 60590 --> https://bugs.winehq.org/attachment.cgi?id=60590 The sourcebrella-pinpoint screenshot of a memory leak defect. We find a memory leak defect in the file tools/winebuild/spec32.c I've uploaded a screenshot of the leak trace. The function build_args_string() will allocate a piece of new mem and it should be freed when finish using. Gang Sourcebrella -- 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 0

[Bug 44598] New: Hebrew font: rendering of vowels is offset
by wine-bugs＠winehq.org 25 Feb '18

25 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=44598 Bug ID: 44598 Summary: Hebrew font: rendering of vowels is offset Product: Wine Version: 3.2 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: chris(a)vine-cottage.org.uk Created attachment 60587 --> https://bugs.winehq.org/attachment.cgi?id=60587 Comparison of font rendering in wine and Windows Using theWord http://www.theword.net/index.php?article.download&l=english to view a Hebrew bible, the font rendering of Hebrew vowel points is incorrect. All fonts I have tried show inconsistencies, the best font appears to be Cardo. In the attached image, the top 2 lines of text shows the font rendering in Wine. The bottom 2 lines of text are the same text rendered in Windows 7. I have circled some of the incorrect rendering in Red. Other fonts show more significant offsets of vowel points from the correct positions. -- 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 0

[Bug 41633] New: Dark GTK3 Labels are white
by wine-bugs＠winehq.org 25 Feb '18

25 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=41633 Bug ID: 41633 Summary: Dark GTK3 Labels are white Product: Wine-staging Version: 1.9.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: electricprism(a)gmail.com CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- Created attachment 56008 --> https://bugs.winehq.org/attachment.cgi?id=56008 wine gtk dark theme black text When using GTK3, and a dark theme the labels on tabs have the text black instead of white. This is visible in both Notepad++ and also WineCFG -- 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 36849] New: eTax 2014 installation under Wine on Linux Mint 17 Qiana
by wine-bugs＠winehq.org 25 Feb '18

25 Feb '18

http://bugs.winehq.org/show_bug.cgi?id=36849 Bug ID: 36849 Summary: eTax 2014 installation under Wine on Linux Mint 17 Qiana Product: Wine Version: 1.6.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: davidcousens(a)bigpond.com Created attachment 48937 --> http://bugs.winehq.org/attachment.cgi?id=48937 Wine backtrace while trying to install Etax 2014 Hi, When trying to install the ATO eTax application under Wine on a Linux Mint 17 system the installation reported an an error with rundll32.exe. -- 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 17

[Bug 43654] New: Arx Fatalis: Candlelight / Porch light leaks through the walls
by wine-bugs＠winehq.org 25 Feb '18

25 Feb '18

https://bugs.winehq.org/show_bug.cgi?id=43654 Bug ID: 43654 Summary: Arx Fatalis: Candlelight / Porch light leaks through the walls Product: Wine Version: 2.9 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: wylda(a)volny.cz Distribution: --- Created attachment 59083 --> https://bugs.winehq.org/attachment.cgi?id=59083 lights through the wall Game works fine in wine-2.7. It's bit broken in wine-2.8 (some black frames with just porch light). Commit wine-2.8-212-g2ed609f15d fixes those black screens with porch light, but also intensifies those porch lights, that it leaks through the wall. Attachment shows that better. commit 2ed609f15da7c7f8bde54f6d4d895c72f96dd950 Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed May 24 11:22:09 2017 +0200 wined3d: Add a conversion function for WINED3DFMT_X8D24_UNORM. Problems remain in current version (wine-2.16) -- 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 6

[Bug 21085] New: Comctl32 status control uses tooltip window wrongly
by wine-bugs＠winehq.org 24 Feb '18

24 Feb '18

http://bugs.winehq.org/show_bug.cgi?id=21085 Summary: Comctl32 status control uses tooltip window wrongly Product: Wine Version: 1.1.35 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: comctl32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: us(a)edmeades.me.uk I've been debugging a private application and tracked down the source of a trap to the way the status control initializes and uses the tooltip control. The application in question traps because it receives a WM_CREATE message for the tooltip window and calls GetWindowLong against an hwnd for a value it should have set earlier - this fails but the code doesnt notice, and results in a trap. On windows, the status control does not create the tooltip until the first WM_MOUSEMOVE event, and hence all application initialization would have finished in my case. You can clearly see this by use of a simple application with a statusbar control set to have a tooltip and text, and then use SPY++ to monitor the window creation messages. Note this also shows a 2nd problem which is that the status control passes the tooltip text to the tooltip window to manage. This is wrong, because using the status bar you can set and then get the tooltip text before the tooltip window is ever created. Additionally, SPY++ shows that the notify messages (NEEDTEXT type) are sent to the status window when the tooltip needs the text, both of which mean that the status control should manage the text. I have a simple application which has a button for get tip, set tip text, and using it you can see the behaviour above. It doesnt replicate the trap but you can see the behavious using it - you dont get a WM_CREATE for the tooltip until such time as you move the mouse into the statusbar area on windows. Simple workarounds for me: winetricks comctl32, or modifying the STATUSBAR_WMCreate method to something like "if (0 && dwStyle & SBT_TOOLTIPS) {" to prevent the tooltip altogether. JECC JECC -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 12

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 2018