November 2019 - Wine-bugs - list.winehq.org

[Bug 48189] New: Track when an account was last used, expire unused accounts
by WineHQ Bugzilla 28 Nov '19

28 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=48189 Bug ID: 48189 Summary: Track when an account was last used, expire unused accounts Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- 1. We have a number of accounts which have a password reset code but no password. This means the account was never used. 2. We also have accounts with both a password and a password reset code. It's quite possible these accounts are no longer used. 3. Some accounts may belong to people who no longer work on Wine and thus be unused. 4. We also have some duplicates for when users had trouble creating their account. The problem with cleaning up all these cases is that there is no record of when an account was last used. So it's impossible to know if an account has been sitting unused for a few days or a few years. This also makes it impossible to reset the password reset code after a while. -- 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 40744] New: NtLockFile I/ O completion on lock breaks Strawberry Perl CPAN
by wine-bugs＠winehq.org 28 Nov '19

28 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=40744 Bug ID: 40744 Summary: NtLockFile I/O completion on lock breaks Strawberry Perl CPAN Product: Wine Version: 1.9.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: alexchandel(a)gmail.com Distribution: --- Strawberry perl (5.24.0.1, 32bit) cannot install any CPAN packages because of the "fixme:ntdll:NtLockFile I/O completion on lock not implemented yet" issue. For example, running cpan and then typing `install Log::Log4perl` in the CPAN shell results in the following message being repeated ad infinitum: ``` Fetching with LWP: http://cpan.strawberryperl.com/authors/01mailrc.txt.gz fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x01b6 ignored fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x01b6 ignored Waiting for a read lock on 'L:\opt\strawberry-perl-5.24.0.1-32bit-portable\cpan\FTPstats.yml' (since Tue Jun 7 12:30:45 2016) Waiting for a read lock on 'L:\opt\strawberry-perl-5.24.0.1-32bit-portable\cpan\FTPstats.yml' (since Tue Jun 7 12:30:45 2016) Waiting for a read lock on 'L:\opt\strawberry-perl-5.24.0.1-32bit-portable\cpan\FTPstats.yml' (since Tue Jun 7 12:30:45 2016) ... ... ``` CPAN never comes back, and cannot install any packages. -- 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 18

[Bug 36268] New: valgrind shows several leaks in dmloader/tests/loader.c
by wine-bugs＠winehq.org 28 Nov '19

28 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=36268 Bug ID: 36268 Summary: valgrind shows several leaks in dmloader/tests/loader.c Product: Wine Version: 1.7.18 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: directx-dmusic Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==4220== 880 bytes in 1 blocks are definitely lost in loss record 783 of 872 ==4220== at 0x7BC4C735: notify_alloc (heap.c:255) ==4220== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==4220== by 0x5F8C7C8: create_dmcontainer (container.c:917) ==4220== by 0x5F8DA8F: ClassFactory_CreateInstance (dmloader_main.c:101) ==4220== by 0x4D3AE26: CoCreateInstance (unknwn.h:226) ==4220== by 0x49558D7: test_COM_container (loader.c:189) ==4220== by 0x4955CB4: func_loader (loader.c:234) ==4220== by 0x4956AB0: run_test (test.h:584) ==4220== by 0x4956E9E: main (test.h:654) ==4220== ==4280== 104 bytes in 1 blocks are possibly lost in loss record 566 of 872 ==4280== at 0x7BC4C735: notify_alloc (heap.c:255) ==4280== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==4280== by 0x5FD0389: create_dmsegment (segment.c:1340) ==4280== by 0x5FBC088: ClassFactory_CreateInstance (dmime_main.c:100) ==4280== by 0x4D3AE26: CoCreateInstance (unknwn.h:226) ==4280== by 0x5F8FA9B: IDirectMusicLoaderImpl_GetObject (loader.c:312) ==4280== by 0x495525E: test_simple_playing (loader.c:110) ==4280== by 0x4955CAA: func_loader (loader.c:232) ==4280== by 0x4956AB0: run_test (test.h:584) ==4280== by 0x4956E9E: main (test.h:654) ==4280== ==4327== 56 bytes in 1 blocks are possibly lost in loss record 431 of 876 ==4327== at 0x7BC4C735: notify_alloc (heap.c:255) ==4327== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==4327== by 0xC1632EC: MMDRV_InitPerType (lolvldrv.c:384) ==4327== by 0xC163C4D: MMDRV_Install (lolvldrv.c:476) ==4327== by 0xC16416F: MMDRV_Init (lolvldrv.c:547) ==4327== by 0xC161F4B: MMDRV_InitSingleType (lolvldrv.c:78) ==4327== by 0xC161FEE: MMDRV_GetNum (lolvldrv.c:89) ==4327== by 0xC17F7C8: midiOutGetNumDevs (winmm.c:284) ==4327== by 0x800E004: create_system_ports_list (dmusic.c:328) ==4327== by 0x800E5C7: DMUSIC_CreateDirectMusicImpl (dmusic.c:436) ==4327== by 0x800EABB: ClassFactory_CreateInstance (dmusic_main.c:100) ==4327== by 0x4D4AE26: CoCreateInstance (unknwn.h:226) ==4327== by 0x5FD5DA9: IDirectMusicPerformance8Impl_Init (performance.c:286) ==4327== by 0x5FD8498: IDirectMusicPerformance8Impl_InitAudio (performance.c:930) ==4327== by 0x4954F82: test_simple_playing (loader.c:83) ==4327== by 0x4955CAA: func_loader (loader.c:232) ==4327== by 0x4956AB0: run_test (test.h:584) ==4327== by 0x4956E9E: main (test.h:654) ==4327== ==4366== 16 bytes in 1 blocks are definitely lost in loss record 150 of 880 ==4366== at 0x7BC4C735: notify_alloc (heap.c:255) ==4366== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==4366== by 0x5FA2379: create_dmloader (loader.c:899) ==4366== by 0x5F9DA8F: ClassFactory_CreateInstance (dmloader_main.c:101) ==4366== by 0x4D4AE26: CoCreateInstance (unknwn.h:226) ==4366== by 0x4955605: test_COM (loader.c:152) ==4366== by 0x4955CAF: func_loader (loader.c:233) ==4366== by 0x4956AB0: run_test (test.h:584) ==4366== by 0x4956E9E: main (test.h:654) ==4366== ==4511== 44 bytes in 1 blocks are definitely lost in loss record 384 of 872 ==4511== at 0x7BC4C735: notify_alloc (heap.c:255) ==4511== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==4511== by 0x5FA3B1E: create_dmaudiopath (audiopath.c:642) ==4511== by 0x5FB09FE: IDirectMusicPerformance8Impl_CreateStandardAudioPath (performance.c:1033) ==4511== by 0x5FB05BF: IDirectMusicPerformance8Impl_InitAudio (performance.c:952) ==4511== by 0x4944F82: test_simple_playing (loader.c:83) ==4511== by 0x4945CAA: func_loader (loader.c:232) ==4511== by 0x4946AB0: run_test (test.h:584) ==4511== by 0x4946E9E: main (test.h:654) ==4511== ==4877== 44 bytes in 1 blocks are definitely lost in loss record 389 of 876 ==4877== at 0x7BC4C735: notify_alloc (heap.c:255) ==4877== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==4877== by 0x5FCBB1E: create_dmaudiopath (audiopath.c:642) ==4877== by 0x5FD89FE: IDirectMusicPerformance8Impl_CreateStandardAudioPath (performance.c:1033) ==4877== by 0x495508B: test_simple_playing (loader.c:93) ==4877== by 0x4955CAA: func_loader (loader.c:232) ==4877== by 0x4956AB0: run_test (test.h:584) ==4877== by 0x4956E9E: main (test.h:654) ==4877== ==4985== 40 bytes in 1 blocks are definitely lost in loss record 366 of 870 ==4985== at 0x7BC4C735: notify_alloc (heap.c:255) ==4985== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==4985== by 0x5F9CCE0: DMUSIC_CreateDirectMusicLoaderResourceStream (loaderstream.c:553) ==4985== by 0x5F9771D: IDirectMusicLoaderImpl_GetObject (loader.c:278) ==4985== by 0x49651A7: test_simple_playing (loader.c:103) ==4985== by 0x4965CAA: func_loader (loader.c:232) ==4985== by 0x4966AB0: run_test (test.h:584) ==4985== by 0x4966E9E: main (test.h:654) ==4985== -- 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 36193] New: valgrind shows some possible leaks in mmdevapi/tests/capture.c
by wine-bugs＠winehq.org 27 Nov '19

27 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=36193 Bug ID: 36193 Summary: valgrind shows some possible leaks in mmdevapi/tests/capture.c Product: Wine Version: 1.7.17 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: mmdevapi Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==11962== 28 bytes in 1 blocks are possibly lost in loss record 99 of 483 ==11962== at 0x7BC4C6B7: notify_alloc (heap.c:255) ==11962== by 0x7BC50EFB: RtlAllocateHeap (heap.c:1716) ==11962== by 0x4FC483E: COMPOBJ_DllList_Add (compobj.c:526) ==11962== by 0x4FC6B7A: apartment_getclassobject (compobj.c:1335) ==11962== by 0x4FCA2C4: get_inproc_class_object (compobj.c:2894) ==11962== by 0x4FCA783: CoGetClassObject (compobj.c:3032) ==11962== by 0x4FCAD45: CoCreateInstance (compobj.c:3197) ==11962== by 0x4E5F328: func_capture (capture.c:1081) ==11962== by 0x4E74EAF: run_test (test.h:584) ==11962== by 0x4E7529E: main (test.h:654) ==11962== ==12008== 76 bytes in 1 blocks are possibly lost in loss record 225 of 481 ==12008== at 0x7BC4C6B7: notify_alloc (heap.c:255) ==12008== by 0x7BC50EFB: RtlAllocateHeap (heap.c:1716) ==12008== by 0x652ED88: create_session (mmdevdrv.c:1038) ==12008== by 0x652EE82: get_audio_session (mmdevdrv.c:1068) ==12008== by 0x6530737: AudioClient_Initialize (mmdevdrv.c:1460) ==12008== by 0x4E4DBC8: test_audioclient (audioclient.h:315) ==12008== by 0x4E52477: func_capture (capture.c:1099) ==12008== by 0x4E67EAF: run_test (test.h:584) ==12008== by 0x4E6829E: main (test.h:654) ==12008== -- 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 3

[Bug 36239] New: valgrind shows a potential leak in cryptnet/tests/cryptnet.c
by wine-bugs＠winehq.org 27 Nov '19

27 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=36239 Bug ID: 36239 Summary: valgrind shows a potential leak in cryptnet/tests/cryptnet.c Product: Wine Version: 1.7.18 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==25097== 2,664 bytes in 74 blocks are possibly lost in loss record 295 of 312 ==25097== at 0x7BC4C735: notify_alloc (heap.c:255) ==25097== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==25097== by 0x4D639FE: CryptMemAlloc (main.c:124) ==25097== by 0x4D769BD: init_oid_info (oid.c:1403) ==25097== by 0x4D77347: crypt_oid_init (oid.c:1613) ==25097== by 0x4D63578: DllMain (main.c:46) ==25097== by 0x4D8B522: __wine_spec_dll_entry (dll_entry.c:40) ==25097== by 0x7BC52FC0: ??? (loader.c:138) ==25097== by 0x7BC555FE: MODULE_InitDLL (loader.c:1068) ==25097== by 0x7BC5597C: process_attach (loader.c:1157) ==25097== by 0x7BC5592C: process_attach (loader.c:1149) ==25097== by 0x7BC5592C: process_attach (loader.c:1149) ==25097== by 0x7BC59F29: attach_process_dlls (loader.c:2769) ==25097== by 0x401B03C: ??? (port.c:60) -- 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 3

[Bug 36071] New: kernel32/pipe tests fail under valgrind
by wine-bugs＠winehq.org 27 Nov '19

27 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=36071 Bug ID: 36071 Summary: kernel32/pipe tests fail under valgrind Product: Wine Version: 1.7.17 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Depends on: 26119 The tests have several valgrind warnings (bug 26119), but also fail under valgrind: austin(a)aw25 ~/wine-valgrind/dlls/kernel32/tests $ rm *ok ; make pipe.ok rm: cannot remove ‘*ok’: No such file or directory ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so pipe && touch pipe.ok preloader: Warning: failed to reserve range 00110000-68000000 preloader: Warning: failed to reserve range 7f000000-82000000 pipe.c:459: Test failed: ConnectNamedPipe pipe.c:469: Test failed: ReadFile pipe.c:470: Test failed: short read pipe.c:473: Test failed: WriteFile pipe.c:480: Test failed: DisconnectNamedPipe pipe.c:459: Test failed: ConnectNamedPipe pipe.c:469: Test failed: ReadFile pipe.c:470: Test failed: short read pipe.c:473: Test failed: WriteFile pipe.c:480: Test failed: DisconnectNamedPipe pipe.c:938: Test failed: client opening named pipe pipe.c:943: Test failed: WriteFile to client end of pipe pipe.c:944: Test failed: write file len pipe.c:946: Test failed: ReadFile from client end of pipe pipe.c:947: Test failed: read file len pipe.c:951: Test failed: CloseHandle pipe.c:938: Test failed: client opening named pipe pipe.c:943: Test failed: WriteFile to client end of pipe pipe.c:944: Test failed: write file len pipe.c:946: Test failed: ReadFile from client end of pipe pipe.c:947: Test failed: read file len pipe.c:951: Test failed: CloseHandle pipe.c:612: Test failed: overlapped ConnectNamedPipe pipe.c:629: Test failed: GetOverlappedResult ConnectNamedPipe pipe.c:640: Test failed: overlapped ReadFile pipe.c:658: Test failed: overlapped ReadFile pipe.c:664: Test failed: overlapped WriteFile pipe.c:682: Test failed: overlapped WriteFile pipe.c:687: Test failed: DisconnectNamedPipe pipe.c:938: Test failed: client opening named pipe pipe.c:943: Test failed: WriteFile to client end of pipe pipe.c:944: Test failed: write file len pipe.c:946: Test failed: ReadFile from client end of pipe pipe.c:947: Test failed: read file len pipe.c:951: Test failed: CloseHandle pipe.c:734: Test failed: overlapped ConnectNamedPipe got 0 err 231 pipe.c:761: Test failed: overlapped ReadFile, err=233 pipe.c:938: Test failed: client opening named pipe pipe.c:943: Test failed: WriteFile to client end of pipe pipe.c:944: Test failed: write file len pipe.c:946: Test failed: ReadFile from client end of pipe pipe.c:947: Test failed: read file len pipe.c:951: Test failed: CloseHandle pipe.c:938: Test failed: client opening named pipe pipe.c:943: Test failed: WriteFile to client end of pipe pipe.c:944: Test failed: write file len pipe.c:946: Test failed: ReadFile from client end of pipe pipe.c:947: Test failed: read file len pipe.c:951: Test failed: CloseHandle pipe.c:938: Test failed: client opening named pipe pipe.c:943: Test failed: WriteFile to client end of pipe pipe.c:944: Test failed: write file len pipe.c:946: Test failed: ReadFile from client end of pipe pipe.c:947: Test failed: read file len pipe.c:951: Test failed: CloseHandle pipe.c:764: Test failed: ReadFile GetQueuedCompletionStatus failed, errno=258 pipe.c:776: Test failed: overlapped WriteFile failed, err=233 pipe.c:427: Test failed: alarm Makefile:529: recipe for target 'pipe.ok' failed make: *** [pipe.ok] Error 1 note that this is a separate issue from bug 35781. -- 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 3

[Bug 46342] New: kernel32/tests/ pipe.c shows uninitialized memory use in test_TransactNamedPipe()
by wine-bugs＠winehq.org 27 Nov '19

27 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=46342 Bug ID: 46342 Summary: kernel32/tests/pipe.c shows uninitialized memory use in test_TransactNamedPipe() Product: Wine Version: 4.0-rc3 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase, valgrind Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: Gentoo ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so pipe && touch pipe.ok ==8919== Syscall param writev(vector[...]) points to uninitialised byte(s) ==8919== at 0x4356813: writev (writev.c:26) ==8919== by 0x7BC75457: send_request (server.c:228) ==8919== by 0x7BC76158: server_call_unlocked (server.c:288) ==8919== by 0x7BC916EC: virtual_locked_server_call (virtual.c:2083) ==8919== by 0x7BC41C1A: server_ioctl_file (file.c:1533) ==8919== by 0x7BC447A5: NtFsControlFile (file.c:1733) ==8919== by 0x7B470FA4: TransactNamedPipe (sync.c:1747) ==8919== by 0x4B26CCC: _overlapped_transact_failure (pipe.c:3118) ==8919== by 0x4B2748E: test_TransactNamedPipe (pipe.c:3346) ==8919== by 0x4B27817: func_pipe (pipe.c:3735) ==8919== by 0x4B6E8E4: run_test (test.h:617) ==8919== by 0x4B6F322: main (test.h:701) ==8919== Address 0x4eafd22 is on thread 1's stack ==8919== in frame #8, created by test_TransactNamedPipe (pipe.c:3341) ==8919== Uninitialised value was created by a stack allocation ==8919== at 0x4B27446: test_TransactNamedPipe (pipe.c:3341) ==8919== -- 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 48182] New: Jasc Paint Shop Pro 8 crash when using some tools
by WineHQ Bugzilla 27 Nov '19

27 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=48182 Bug ID: 48182 Summary: Jasc Paint Shop Pro 8 crash when using some tools Product: Wine Version: 4.0.3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: myrvina(a)caramail.fr Distribution: --- Created attachment 65820 --> https://bugs.winehq.org/attachment.cgi?id=65820 Detail of error message in Paint Shop Pro 8 after using smudge tool Update from ppa from latest stable version of WineHq to version 4.03. Jasc Paint Shop Pro 8 (English version) was working fine but now crashes on using some tools such as preset shape tool, smudge, lighten/darken, soften brushes, magic wands while other tools including filters work fine. Enclosing the message I got from crash. -- 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 48179] New: When trying to buy gems from the store on MtGArena application crashes complaining about ZFGameBrowser.exe
by WineHQ Bugzilla 26 Nov '19

26 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=48179 Bug ID: 48179 Summary: When trying to buy gems from the store on MtGArena application crashes complaining about ZFGameBrowser.exe Product: Wine Version: 4.0.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alecfvn(a)gmail.com Distribution: --- Created attachment 65814 --> https://bugs.winehq.org/attachment.cgi?id=65814 Backtrace for trying to buy gems from the store In MtGArena, when I try to buy gems from the store, it tries to load the store and then crashes the app complaining about ZFGameBrowser.exe with the attached backtrace. I'm running Kubuntu 18.04 and Wine 4.0.2. System information for the app: Wine build: wine-3.20 Platform: i386 (WOW64) Version: Windows 10 Host system: Linux Host version: 4.15.0-70-generic -- 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 10

[Bug 48166] New: test.winehq.org Provide a way to track individual failures
by WineHQ Bugzilla 26 Nov '19

26 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=48166 Bug ID: 48166 Summary: test.winehq.org Provide a way to track individual 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: --- A test unit may have multiple unrelated test failures. Some may fail on recent Windows 10 machines while others may only happen in certain locales or some graphics cards. Untangling these can actually be automated. The root is to merge the failures of two reports together while associating each failure with the tag or the report(s) it originates from. To do so diff the two error lists. * Failures that are present in both get both tags. * Failures that are only present in the first report get only that tag. * Same thing for failures that are present only in the second report. And all failures are integrated in the merged list in the order they are returned in by Algorithm::Diff. Once two failure lists have been merged together, it's possible to continue merging more failure lists. This allows getting a unified list of the failures of a given commitid, and appending that commitid to the tags allows building a complete list of all the available history. Then one can group all failures that have the exact same set of tag+commitids combinations together. Then, since the failures in different groups don't all happen together they must depend on different factors. Intermittent failures, timeouts, crashes ---------------------------------------- If two failures are related but a random timeout or crash sometimes occurs between them they might end up being incorrectly split in two separate groups. So if a crash or a timeout occurs, any other failure in that run should be ignored when grouping failures together. This can be achieved by prefixing the tag with a '*' if a crash or timeout occured. Then, when grouping failures together, ignore the entries where the tag starts with a '*'. But when building the occurence pattern, do use the entries starting with a '*' to show all the test runs where at least one of the failures in the group occurred. Because entries starting with a '*' are ignored when building failure groups, failures that cause a crash/timeout and the crash/timeout line itself will be part of no failure group. So do a second pass over the unassigned failures, this time not ignoring the entries with a '*'. This will create groups composed of the crash/timeout and any related failures. New failures ------------ This analysis indicates where and when a given failure group happened. This means it can also detect new failures. It would not be useful to define a new failure as one that never happened before the latest commit: blink and you might miss it. Instead it should be expanded to all failures that only happened in the first half of the available history. This may sometimes falsely treat rare intermittent failures as new but that should be rare enough. Presentation of the results --------------------------- The results can be presented on a page with one box per test unit like the 'Full Report' pages. A 'details' link under the test unit name on the test failrues pattern page would link to the relevant section of the full page. Inside each box there would be a sequence of lines showing the failures in a group, followed by the usual pattern showing which machines the failure happens on; then the next failure group, etc. For instance: console.c:270: Test failed: got 16, expected 6 console.c:275: Test failed: got 16, expected 6 .....F..F...F..F.mmm Win8 vm1 ......FF.e...FF.e..F Win8 vm1-ja 096c:console: unhandled exception c0000005 at 6F384E33 .....CC Win8 vm2-new As usual the items in the pattern would link to the relevant pages, allowing to dig deeper into the issue. The same color coding would be used for the pattern but since failure groups always have the same number of failures only one color would be used for the F code. The failure line number will change from one run to the next so zero it out or only retain one value at random. Similarly, if the failure contains timing information (see bug 48094), remove the timing information. If a failure is identified as new, put its lines in bold orange, like on the TestBot. This will allow quick identification of the new failures on the page. -- 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