Re: Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09ef

["Constantine Gavrilov" <CONSTG () il ibm com>]

Ronnie:

Thank you for taking your time to reply. I think you entirely missed my 
point.

The question was not regarding how to fix but about significance of this 
build test.

I saw my previous merge requests approved and  even merged when this test 
failed. I then saw it  post factum, and voluntarily updated code in next 
commits.

I also get only occasional reminder about this -- I do not understand why 
it is not linked to MR, or why MR does not indicate build failure.

You are asking why core developers shall care? Obviously, this additional 
build test was implemented by the project, not by me, as well as unique 
compile options for CLNAG-11 that make the build to fail while other 
compilers succeed. Obviously,  the was some purpose and thought in this. I 
do not think it is documented anywhere, so it was a reasonable question.

I fail to see how this innocuous question can "rub you in a serious way" 
or rub other "helpful people". You have made it sound very personal and 
none of my communications were. If you have issues with other 
communications I would recommend you reply in the context of those threads 
and not this one.

There is no reason to use a context of a technical question as means of a 
personal "rub".

Can someone answer my question regarding additional build pipeline please?


--
----------------------------------------
Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv Storage Lab IDT Lead
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
----------------------------------------



From:   ronnie sahlberg <ronniesahlberg () gmail com>
To:     Developer support list for Wireshark <wireshark-dev () wireshark org>
Date:   03/31/2021 10:41 AM
Subject:        [EXTERNAL] Re: [Wireshark-dev] Failed pipeline for 
nvmeof_getlog_page | wireshark | 3a8e09ef
Sent by:        "Wireshark-dev" <wireshark-dev-bounces () wireshark org>



It seems like you already know what is wrong and how to solve this. Why 
not just change your patch so it does not trigger this compiler 
error/warning? Maybe the compiler is overly sensitive here? Who knows. Why 
is this a problem for wireshark ZjQcmQRYFpfptBannerStart 
This Message Is From an External Sender 
This message came from outside your organization. 
ZjQcmQRYFpfptBannerEnd
It seems like you already know what is wrong and how to solve this.
Why not just change your patch so it does not trigger this compiler 
error/warning?


Maybe the compiler is overly sensitive here? Who knows.
Why is this a problem for wireshark developers?

Do this:
* fix your code so it does not trigger the warnings.  Wireshark developers 
are not supposed to 
keep track of what are false warnings that are bogus or what are real 
problems.
* if you have a problem with the compiler, bring it up with them. we are 
not compiler developers or maintainers.
* work on your people skills. You are rubbing people that could help you 
in seriosly the wrong way.


On Wed, Mar 31, 2021 at 5:21 PM Constantine Gavrilov <CONSTG () il ibm com> 
wrote:
I have a question regarding for a special form of automatic builds that I 
do not understand.

Occasionally, I get an email for additional pipeline build that is 
different from default pipeline linked to the ticket. It is a wider set of 
compilers and distributions.

Several questions:
1.      What is the significance of this and when it is triggered?
2.      Why it is not linked to MR (meaning I cannot see this failure in 
MR)?
3.      Shall I fix these failures?
4.      How do I know that the issue is fixed, since such builds are not 
linked to MR?
I have looked at this particular one, and it is a a bug in compiler:

guint64 off =...; /* take from command context, now looking at reply */
if (off < 40)
        proto_add_item(...., .... 40-off,.....);

So, the error (in CLANG-11) is (40-off) is 64-bit and passing it as 32-bit 
parameter "looses high-order bits".

First, the compiler shall see that no loss of value takes place because of 
the "IF" statement here. Second, since when passing 64-bit value as a 
32-bit parameter shall be a compiler error in C language?

I can easily fix this (check the value in saved context, and if it is 
above possible payload length return, then declare off as 32-bit), but I 
need to know if CLANG-11 (with draconian compile options) is a MUST to 
pass. 


-
----------------------------------------
Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv Storage Lab IDT Lead
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
----------------------------------------
----- Forwarded by Constantine Gavrilov/Israel/IBM on 03/31/2021 10:07 AM 
-----

From:        GitLab <gitlab () mg gitlab com>
To:        
Date:        03/30/2021 05:37 PM
Subject:        [EXTERNAL] Failed pipeline for nvmeof_getlog_page | 
wireshark | 3a8e09ef
Sent by:        gitlab () mg gitlab com


Pipeline #278885577 has failed!   Project Constantine Gavrilov / wireshark 
Branch nvmeof_getlog_page Commit 
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender 
This message came from outside your organization. 
ZjQcmQRYFpfptBannerEnd






Pipeline #278885577 has failed! 

  

Project
Constantine Gavrilov / wireshark 
Branch


nvmeof_getlog_page 

Commit


3a8e09ef 
NVMe: Get LogPage: Commands Supported and Effects 
Commit Author


Constantine Gavrilov 


  

Pipeline #278885577 triggered by 

Constantine Gavrilov 

had 1 failed build. 
Failed builds 



build 

clang-11 




You're receiving this email because of your account on gitlab.com. Manage 
all notifications · Help




___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org
?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    
https://www.wireshark.org/lists/wireshark-dev 

Unsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 

             
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe