Wine FIXME Report January 2010
Wine FIXME Report January 2010 ============================== The data for this report comprise the emails from January 2010 archives of the mailing lists wine-{bugs,devel,users} as well as the bugzilla attachments referenced by the wine-bugs emails. Although WARN messages were collected too they aren't handled in this report. File parsed: 6364 (emails: 5850, bugzilla attachments: 514) Files with FIXME/ERR/WARN: 436 Type | Total | Unique ------+---------+------- fixme | 1354429 | 8122 err | 24115 | 993 warn | 3491 | 404 The Most Popular Messages ------------------------- This are the most prevalent ERR and FIXME messages aka the number of files where they show up. FIXME: Files | Lines | Channel:Function Text ------+-------+---------------------- 59 | 119 | d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface 42 | 45 | system:SetProcessDPIAware stub! 36 | 46 | iphlpapi:GetAdaptersAddresses no support for IPv6 addresses 33 | 61 | mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer 29 | 57 | urlmon:URLMoniker_BindToObject use running object table 22 | 41 | shdocvw:BindStatusCallback_OnProgress status code 11 19 | 21 | system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS) 18 | 21 | resource:GetGuiResources (0xffffffff,0): stub 18 | 37 | shdocvw:PropertyNotifySink_OnChanged unimplemented dispid 1005 17 | 71 | storage:StgCreateDocfile Storage share mode not implemented. ERR: Files | Lines | Channel:Function Text ------+-------+---------------------- 22 | 41 | alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element 18 | 25 | ole:CoGetClassObject class {9a5ea990-3034-4d6f-9128-01f3c61022bc} not registered 18 | 26 | ole:CoGetClassObject no class object {9a5ea990-3034-4d6f-9128-01f3c61022bc} could be created for context 0x1 15 | 1646 | ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 58 14 | 1645 | ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 64 12 | 44 | ole:CoGetClassObject class {6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered 12 | 44 | ole:CoGetClassObject no class object {6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1 12 | 114 | ole:apartment_getclassobject DllGetClassObject returned error 0x80040111 10 | 18 | rpc:I_RpcGetBuffer no binding 9 | 12 | ole:CoGetClassObject class {77f10cf0-3db5-4966-b520-b7c54fd35ed6} not registered Noisy Popular Messages ---------------------- The noisiest messages that show up at least in 1% of the collected reports. FIXME: Lines | Files | Channel:Function Text ------+-------+---------------------- 223 | 7 | mshtml:nsChannel_GetSecurityInfo default action not implemented 155 | 11 | ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 144 | 12 | wininet:InternetLockRequestFile STUB 119 | 59 | d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface 110 | 9 | advapi:LsaClose (0xcafe) stub 99 | 8 | font:WineEngAddFontResourceEx Ignoring flags 10 92 | 5 | wininet:GetUrlCacheEntryInfoExW Undocumented flag(s): 100 75 | 7 | file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented 71 | 17 | storage:StgCreateDocfile Storage share mode not implemented. 61 | 33 | mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer ERR: Lines | Files | Channel:Function Text ------+-------+---------------------- 1646 | 15 | ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 58 1645 | 14 | ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 64 114 | 12 | ole:apartment_getclassobject DllGetClassObject returned error 0x80040111 113 | 6 | ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002 66 | 7 | ole:ITypeInfo_fnInvoke did not find member id -504, flags 0x2! 66 | 7 | ole:ITypeInfo_fnInvoke did not find member id -514, flags 0x2! 62 | 6 | shell:SHGetFileInfoW pidl is null! 44 | 12 | ole:CoGetClassObject class {6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered 44 | 12 | ole:CoGetClassObject no class object {6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1 41 | 22 | alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element Noisy Popular Functions ----------------------- The noisiest functions that show up at least in 1% of the collected reports. FIXME: Lines | Files | Channel:Function ------+-------+----------------- 434041 | 716 | ole:NdrCorrelationInitialize 434009 | 716 | ole:NdrCorrelationFree 7620 | 6 | d3d:context_check_fbo_status 2716 | 100 | d3d_surface:IWineD3DVolumeImpl_LockBox 2052 | 8 | d3d_surface:IWineD3DBaseSurfaceImpl_Blt 1531 | 156 | d3d:IWineD3DOcclusionQueryImpl_GetData 738 | 78 | d3d_surface:IWineD3DSurfaceImpl_LoadLocation 653 | 497 | shdocvw:ClOleCommandTarget_Exec 466 | 84 | dsound:IDirectSoundBufferImpl_AcquireResources 418 | 197 | mshtml:nsChannel_GetSecurityInfo ERR: Lines | Files | Channel:Function ------+-------+----------------- 16107 | 37 | ole:ITypeInfo_fnInvoke 3291 | 29 | ddraw:PixelFormat_WineD3DtoDD 872 | 201 | ole:CoGetClassObject 180 | 27 | x11settings:X11DRV_ChangeDisplaySettingsEx 174 | 26 | ole:create_server 121 | 16 | ole:apartment_getclassobject 113 | 6 | ole:ClientIdentity_QueryMultipleInterfaces 113 | 6 | ole:marshal_object 69 | 63 | eventlog:ReportEventW 62 | 6 | shell:SHGetFileInfoW The Top Ten Single Charts ------------------------- This are the messages with the most occurrences in a single file. FIXME: Lines | Files | Channel:Function Text ------+-------+---------------------- 433829 | 4 | rpc:NdrStubCall2 new correlation description not implemented 61256 | 1 | ole:NdrCorrelationFree (0x33df38): stub 61224 | 1 | ole:NdrCorrelationInitialize (0x33df38, 0x33db38, 1024, 0x0): stub 60612 | 1 | ole:NdrCorrelationInitialize (0x33d414, 0x33d014, 1024, 0x0): stub 60611 | 1 | ole:NdrCorrelationFree (0x33d414): stub 50370 | 1 | ole:NdrCorrelationInitialize (0x33d694, 0x33d294, 1024, 0x0): stub 50364 | 1 | ole:NdrCorrelationFree (0x33d694): stub 29000 | 1 | ole:NdrCorrelationInitialize (0x33d764, 0x33d364, 1024, 0x0): stub 28994 | 1 | ole:NdrCorrelationFree (0x33d764): stub 17768 | 1 | ole:NdrCorrelationInitialize (0x33d6ec, 0x33d2ec, 1024, 0x0): stub ERR: Lines | Files | Channel:Function Text ------+-------+---------------------- 13032 | 1 | ole:ITypeInfo_fnInvoke did not find member id 512, flags 0x4! 1728 | 1 | ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_I4 from VT_BSTR 864 | 1 | ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_BOOL from VT_BSTR 837 | 15 | ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 58 837 | 14 | ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 64 756 | 1 | d3d_surface:IWineD3DBaseSurfaceImpl_CreateDIBSection CreateDIBSection failed! 331 | 1 | d3d:IWineD3DImpl_IsPixelFormatCompatibleWithRenderFmt Unable to check compatibility for Format=WINED3DFMT_R32G32B32A32_FLOAT 331 | 1 | d3d:getColorBits Unsupported format: WINED3DFMT_R32G32B32A32_FLOAT 288 | 1 | ole:ITypeInfo_fnInvoke did not find member id 854, flags 0x4! 198 | 3 | d3d:state_undefined Undefined state. Further Info: ------------- The sqlite3 database and the SQL commands to output the above info can be downloaded from http://people.redhat.com/mstefani/winefixme/reports/201001/ bye michael
I'm pretty sure if I read the code I would understand this report better but I was not curious enough and unfortunately that means I'm pretty confused now. It seems the data is sliced three ways: * The Most Popular Messages - Based on the name it sounds like someone voted on them, but then the definition says they 'are the most prevalent' which sounds like they are just the most frequent ones. - So I look at the number of lines where they show up and the number one shows up in just 119 lines, while some way down it seems there are some that show up in hundreds of thousands of lines. So I'm lost. - It also does not help that the order of the Files and Lines column is reversed compared to all the other sections. * Noisy Popular Messages / Functions - So here the definition says they 'show up at least in 1% of the collected reports', so it sounds like it's the messages/functions that impact the most reports. So it's most frequent per report count. - They are still sorted by Line count though. Shouldn't they be sorted some other way? - Is there a difference between a file and a report? * The Top Ten Single Charts - These really look like they are the most frequent by line count (based on the line count). But I have some doubts. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?
On 02/09/2010 12:01 AM, Francois Gouget wrote:
I'm pretty sure if I read the code I would understand this report better but I was not curious enough and unfortunately that means I'm pretty confused now. You need to read only the SQL used to generate the tables ;)
It seems the data is sliced three ways: I needed some catchy titles; I know those aren't that great. If somebody has better ideas I'm all ears.
* The Most Popular Messages - Based on the name it sounds like someone voted on them, but then the definition says they 'are the most prevalent' which sounds like they are just the most frequent ones. - So I look at the number of lines where they show up and the number one shows up in just 119 lines, while some way down it seems there are some that show up in hundreds of thousands of lines. So I'm lost. With 'prevalent' I mean the number of files that contain that message not how often those show up in that message. Basically the equivalent of grep -l | wc -l and sorted by that number.
Reason: Wine is too noisy and people tend to ignore the "stray" fixme and err messages here and there. They notice only if a message floods the output. Then it gets silenced to print only once and the message disappears from the radar. This tables tries to show the fixme/err messages that a lot of people see and overlook. As a lot of people see them they are "popular". Like the fixme("stub") messages in DllCanUnloadNow() that got fixed aka removed because of this report; everybody was seeing and ignoring them.
- It also does not help that the order of the Files and Lines column is reversed compared to all the other sections.
I did it to make it visible that the table is sorted by the first column aka "Files". Probably dropping the "Lines" column altogether would have made it clearer.
* Noisy Popular Messages / Functions - So here the definition says they 'show up at least in 1% of the collected reports', so it sounds like it's the messages/functions that impact the most reports. So it's most frequent per report count. Not quite. The "The Most Popular Messages" impact the most reports. I came up with this reports after the "The Top Ten Single Charts" turned out to be pretty useless. There are messages that repeat hundreds of thousands of times in *one* single file. And there are no other files out of ~2500 files with that message. While that is annoying for the guy that got that flood, it is statistically irrelevant. Might be his setup; might be a broken commit round, who knows. But those are definitely not worth silencing aka using the if(once++) fixme() trick.
Thus I tried to find fixme/err messages that are noisy (lots of repeated messages in a file) and relevant (1% of the files). I figure Alexandre might be willing to accept the if(once++) fixme() trick for those.
- They are still sorted by Line count though. Shouldn't they be sorted some other way?
I have thought about sorting by the average number of messages per file; I'll look at it tomorrow and see if it makes more sense.
- Is there a difference between a file and a report?
No, not in this context. Though I don't like either of those names: - A file is also an email that has no fixme/err/warn messages. - A report is conflicting with the "Wine FIXME Report". But I couldn't come up with a better name back then. A "log" should be a better name for the files that contain fixme/err/warn messages. But I'm open for other names too.
* The Top Ten Single Charts - These really look like they are the most frequent by line count (based on the line count). But I have some doubts. This are the maximum hits per file and not a sum of all hits. Pretty useless and I've thought about dropping this tables as they aren't statistically relevant; more than 50% of those messages show up in only one file.
bye michael
On Tue, 9 Feb 2010, Michael Stefaniuc wrote: [...]
It seems the data is sliced three ways: I needed some catchy titles; I know those aren't that great. If somebody has better ideas I'm all ears.
I don't know if this is any better than your titles, but here's a try: * Most frequent messages by report Description: Messages that are present in the most reports. * Most frequent messages by line Description: Messages with the highest cummulative line count that are also present in at least 1% of reports. The latter criteria is to eliminate messages that merely have a very high repetition count in a handful of reports. * Messages with highest repetition count Description: Messages with the highest repetition count in a single report. Also: * I think 'log' would be a good name. In any case I'd only use one name throughout, including in the column heading. * I'd always leave the columns in the same order, no matter which one the data is sorted on. The reader should pretty easily figure it out and will have less trouble comparing the tables. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.
9 | 12 | ole:CoGetClassObject class {77f10cf0-3db5-4966-b520-b7c54fd35ed6} not registered
Added to http://wiki.winehq.org/LookupUuidTable and filed bug 21654.
Hi! It would be very nice to know if any of the most reported ERRs, WARNs, FIXMEs etc. from the _previous_ run is now gone (in other words, that it has been fixed/implemented) Thanks, Tomas
It would be very nice to know if any of the most reported ERRs, WARNs, FIXMEs etc. from the _previous_ run is now gone (in other words, that it has been fixed/implemented)
I don't think that's possible to determine from the statistics. Just because we don't see a message, or don't see it as often, doesn't mean it has been solved. Things that have been solved may still appear if people are still using older versions.
On 02/09/2010 08:51 PM, Vincent Povirk wrote: >> It would be very nice to know if any of the most reported ERRs, WARNs, >> FIXMEs etc. from the _previous_ run is now gone (in other words, that it has >> been fixed/implemented) > > I don't think that's possible to determine from the statistics. Just > because we don't see a message, or don't see it as often, doesn't mean > it has been solved. Things that have been solved may still appear if > people are still using older versions. Actually it is fairly "trivial". Of course not from the statistics but from the source code. I have started to work on it some time ago. Basically it boils down to: - Extract the fixme/err format strings from the source code; coccinelle makes this task fairly easy (*done*). - Convert the format string into a regexp. - Match the regexp against the collected messages. The channel and function name already limit the search space a lot. - Profit. Having a few Wine versions in the DB will then allow stuff like "first seen in/last seen in"; with enough messages in a log file one could even fingerprint the Wine version that probably generated that output. Though this isn't the only reason I started this work but in addition to: - To better group the messages together based on the source that generated those. - Provide a quick link from the message in the report to the Wine source code. To lower the barrier to entry so hopefully people will click on that and go "hey, I know how to fix that one". bye michael
Actually it is fairly "trivial". Of course not from the statistics but from the source code.
The source code isn't an accurate indication of which issues have been solved either. If I add a new case to a switch statement or register a new CLSID, it'll stop some messages from appearing, but the ERR/FIXME statements won't disappear. And "this value is not yet handled" is a pretty common sort of message.
On 02/09/2010 10:25 PM, Vincent Povirk wrote:
Actually it is fairly "trivial". Of course not from the statistics but from the source code.
The source code isn't an accurate indication of which issues have been solved either. If I add a new case to a switch statement or register a For a lot of the messages it will be good enough.
new CLSID, it'll stop some messages from appearing, but the ERR/FIXME statements won't disappear. And "this value is not yet handled" is a pretty common sort of message. If the messages stop appearing or they appear less often they will loose their "good placement" in the Wine FIXME statistics or even drop out of sight.
Of course the source code approach has other limitations like missing spelling fixes in the format string, whitespace fixes, etc. But for this task where 100% accuracy isn't needed it is good enough. bye michael
participants (4)
-
Francois Gouget -
Michael Stefaniuc -
Tomas Zijdemans -
Vincent Povirk