Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dir on return value of msilib.OpenDatabase() crashes python #55911

Closed
markm mannequin opened this issue Mar 28, 2011 · 7 comments
Closed

dir on return value of msilib.OpenDatabase() crashes python #55911

markm mannequin opened this issue Mar 28, 2011 · 7 comments
Labels
3.7 (EOL) end of life OS-windows type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@markm
Copy link
Mannequin

markm mannequin commented Mar 28, 2011

BPO 11702
Nosy @loewis, @terryjreedy, @amauryfa, @tjguk, @zware, @serhiy-storchaka, @zooba
Superseder
  • bpo-26906: Special method lookup fails on uninitialized types
  • Files
  • msi_opendatabase.patch
  • msi_opendatabase_2.patch: Patch View, Record & Summary Types also
  • support_dir_for_msi_objs.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2021-10-18.21:23:54.993>
    created_at = <Date 2011-03-28.15:13:42.260>
    labels = ['3.7', 'OS-windows', 'type-crash']
    title = 'dir on return value of msilib.OpenDatabase() crashes python'
    updated_at = <Date 2021-10-18.21:23:54.992>
    user = 'https://bugs.python.org/markm'

    bugs.python.org fields:

    activity = <Date 2021-10-18.21:23:54.992>
    actor = 'iritkatriel'
    assignee = 'none'
    closed = True
    closed_date = <Date 2021-10-18.21:23:54.993>
    closer = 'iritkatriel'
    components = ['Windows']
    creation = <Date 2011-03-28.15:13:42.260>
    creator = 'markm'
    dependencies = []
    files = ['21445', '21466', '22043']
    hgrepos = []
    issue_num = 11702
    keywords = ['patch']
    message_count = 7.0
    messages = ['132402', '132436', '132539', '136201', '136418', '223144', '277920']
    nosy_count = 8.0
    nosy_names = ['loewis', 'terry.reedy', 'amaury.forgeotdarc', 'tim.golden', 'markm', 'zach.ware', 'serhiy.storchaka', 'steve.dower']
    pr_nums = []
    priority = 'normal'
    resolution = 'duplicate'
    stage = 'resolved'
    status = 'closed'
    superseder = '26906'
    type = 'crash'
    url = 'https://bugs.python.org/issue11702'
    versions = ['Python 2.7', 'Python 3.5', 'Python 3.6', 'Python 3.7']

    @markm
    Copy link
    Mannequin Author

    markm mannequin commented Mar 28, 2011

    Running the following code:

    >>> import msilib
    >>> db  = msilib.OpenDatabase('c:/windows/installer/1c7a1.msi', 1)
    >>> db
    <_msi.Database object at 0x01E230A0>
    >>> dir(db)

    (Python crashes - tested on current Trunk and Python 2.7.1).

    I tried tracking it through the C code - and it seems to be a problem when dir is checking for __dir__ (the pointer in PyObject_GetAttrString seems to be incorrect).

    @markm markm mannequin added OS-windows type-crash A hard crash of the interpreter, possibly with a core dump labels Mar 28, 2011
    @amauryfa
    Copy link
    Member

    A call to PyType_Ready() fixes the issue, see attached patch.
    I added a test that opens a random file in c:\windows\installer, I don't know if this is correct for all Windows version.

    @markm
    Copy link
    Mannequin Author

    markm mannequin commented Mar 29, 2011

    That fixed it - but it seems we need that for the other Types defined in the module.

    Regarding testing - would it be a good idea to add an MSI to the test suite - or better to create one during testing (using msilib) and then use that in the tests?

    @briancurtin
    Copy link
    Member

    If we can generate a testable MSI file that would be the best. Including a very small pre-generated MSI for the purposes of the test would be acceptable.

    As-is, the tests don't pass because my machine has C:\Windows\installer\1032f.msi that gets used for the test, which apparently doesn't work with this functionality, and other machines may end up with the same situation. I'm not sure if that's a bug in the code or in whatever MSI that is, though. The OpenDatabase call returns "unknown error 6e" for both new tests.

    @markm
    Copy link
    Mannequin Author

    markm mannequin commented May 21, 2011

    I wasn't so happy trawling through \windows\installer either :)

    Creating an MSI to test is very simple, and actually quicker than I had originally thought. The latest patch (support_dir_for_msi_objs.patch) creates the one and just uses that. Optionally I could create a new one each time setUp()/tearDown(). But was thinking - let's do that if/when we need to :)

    The latest patch updates the tests - but no change to the C code.

    (I doubt the error you received is a bug in msilib, and I couldn't repro even by opening EVERY MSI in my windows\installer dir. It could be a rights/security issue? The previous test was not opening as READ ONLY - even though it never saved the db, so that may be another reason?)

    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jul 15, 2014

    The attached patch is short and sweet and looks okay to my untrained eye. I believe it should apply cleanly as there've been very few changes to _msi.c. Can we have a formal patch review please.

    @terryjreedy
    Copy link
    Member

    This is a generic issue as there are multiple unready types that can raise (or in this case crash) with code that should work. bpo-26906 gives other examples and discussion of possible generic solutions that would make this issue obsolete.

    @terryjreedy terryjreedy added the 3.7 (EOL) end of life label Oct 3, 2016
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 (EOL) end of life OS-windows type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants