hpijs segfault in DJGenericVIP::DJGenericVIP ()

[Martin Wilck]

We see a segfault in DJGenericVIP::DJGenericVIP ():

DJGenericVIP::DJGenericVIP (SystemServices* pSS, BOOL proto)
    : DJ9xxVIP (pSS, proto)
{

    if (!proto && IOMode.bDevID)
    {
        bCheckForCancelButton = TRUE;
        constructor_error = VerifyPenInfo ();
        if (constructor_error != NO_ERROR)
        {
            constructor_error = NO_ERROR;
            ePen = BOTH_PENS;
        }
    }
    else
        ePen = BOTH_PENS;

[...]

    pMode[ModeCount++] = new VIPFastDraftMode (); // Fast Draft

[...]

    for (int i = 0; i < (int) ModeCount; i++)
    {
        pMode[i]->bFontCapable = FALSE;

Crash here, because pMode[0] and pMode[1] are NULL:

(gdb) print pMode
$20 = {0x0, 0x0, 0x55a4dd774ff0, 0x55a4dd7360e0, 0x55a4dd778220, 0x55a4dd7744a0, 0x55a4dd7745a0, 0x55a4dd776170, 0x55a4dd776270,
  0x55a4dd776370, 0x55a4dd7739f0, 0x55a4dd773af0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}

(gdb) print ModeCount
$21 = 12

ModeCount == 12 means that, before this code was run, ModeCount was 2. That's
the value to which ModeCount is initialized in Printer::Printer(). But
DJ9xxVIP::DJ9xxVIP() should have reset ModeCount to 0 and added the
DJ9xx-specific modes. That hasn't happened. According to my analysis, this can
occur if VerifyPenInfo() returns an error. DJGenericVIP::DJGenericVIP()
doesn't treat this as fatal error condition (see above). But it's treated as
an error in the superclass constructor DJ9xxVIP::DJ9xxVIP(), which won't
initialize ModeCount and the pMode list if this happens:

DJ9xxVIP::DJ9xxVIP
(
    SystemServices* pSS,
    BOOL proto
) :
    Printer(pSS, NUM_DJ6XX_FONTS, proto),
    PCL3acceptsDriverware(TRUE)
{

    m_bVIPPrinter = TRUE;

    if (!proto && IOMode.bDevID)
    {
        bCheckForCancelButton = TRUE;
        constructor_error = VerifyPenInfo();
        CERRCHECK;
    }
    else ePen = BOTH_PENS; // matches default mode

See https://bugzilla.opensuse.org/show_bug.cgi?id=1094141 for more details. There's also a core dump there. Matching binaries and debuginfo packages can be retrieved from http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/ and http://download.opensuse.org/debug/distribution/leap/15.0/repo/oss/x86_64/, respectively.

This has been ovserved with an openSUSE build of hplip 3.17.9, but given that the respective source files are unchanged between 3.17.9 and 3.18.5, it's almost certain that the problem is not specific to the SUSE build.

[Martin Wilck (mwilck)]

I came up with this simplistic patch. Still needs verification.

[Martin Wilck (mwilck)]

The patch from comment #1 has been successfully tested by the reporter at SUSE.

https://bugzilla.suse.com/show_bug.cgi?id=1094141#c12

[ashok (ashok1)]

Hi Martin,

Could you please share the exact steps to reproduce the issue.

And also I need some more information like which distro,HPLIP version and model name etc..to do more analysis on this bug.

[Martin Wilck (mwilck)]

Hi

Distro and version information is in the bug description, even the links to the binary package.
For completeness, the source package is here:

http://download.opensuse.org/source/distribution/leap/15.0/repo/oss/src/hplip-3.17.9-lp150.3.2.src.rpm

I've asked the reporter for steps to reproduce.

But don't you think, reading my patch and my analysis, that the bug is quite obvious? I concede that my patch is no more than a hotfix to avoid the segfault. A true solution would need to clean up the class inheritance of the various "Printer" subclasses in hpijs. Setting ModeCount to 2 and relying on other code to fill in pMode[0] and pMode[1], as Printer::Printer() is doing it, looks all but clean to me. And maybe DJGenericVIP shoulldn't be a subclass of DJ9xxVIP after all, looking at how error conditions are handled differently.

[Martin Wilck (mwilck)]

The printer is an old HP Deskjet 1000 110J connected via USB. The reporter said further

"cartridge issue might be, but the printing itself worked, and the ink must
remain enough. That said, I have no slightest idea how it started happening."

[Martin Wilck (mwilck)]

My previously attached patch contained a bug. I mustn't change the default for ignore_pen_error to TRUE in the prototype of DJ9xxVIP::DJ9xxVIP(). The default must be FALSE in order to keep standard behavior for DJ9xxVIP printers which are not DJGenericVIP instances.

[srinivas (srinivas5)]

Hi Martin,

Thanks for your analysis and the patch.
But in order to make the fix, we need to reproduce the issue.
So request you to kindly share the exact steps to reproduce the issue.

Thanks,
Srinivas Teja.

[Martin Wilck (mwilck)]

Srinivas,

I've told you all I know. Please check the links to openSUSE bugzilla above. I haven't reproduced this myself, I don't even have the hardware. An openSUSE user has encountered it and reported it to us. I gave you the available data in comment 5. I just happen to be co-maintainer of hplip for openSUSE.

The user essentially said that the problem suddenly started to occur at a certain point in time, for his Deskjet 1000 110J which used to work fine, with no obvious change in the environment. As the user himself is a highly capable Linux developer, I tend to believe that. Obviously, the crash only occurs in exceptional situations: the condition (!proto && IOMode.bDevID) must be TRUE, and VerifyPenInfo() must return an error. Both conditions are related to the hardware side which you probably understand better than myself. Thus it's reasonable to assume that something has changed on the HW side, perhaps simply by wear-off or resource exhaustion, causing the exception to occur. Maybe you can recommend some debugging steps or tools to gain more insight on that?

That said, repeat: The code analysis is obvious, and so is the situation in the core dump. That should be sufficient for you to go ahead.

Martin

[Martin Wilck (mwilck)]

The user who reported this has given feedback on my patch v2 (comment 6):

> Yes, it worked. Sorry for forgotten update.

> BTW, the issue seems actually related with the ink cartridge. Even the unpatched system works once > after re-inserting the cartridge (temporarily).