Bug#859279: Updating the ygl Uploaders list
Hi Nilesh, Thank you for taking this up. I don't use this package anymore so I am a bit out of touch on the status of the package. Regards, Prabhu On 1/31/22 22:26, Nilesh Patra wrote: > Hi Mattia, Kumar, > > Kumar, would you have any plans to adopt this? > > On Wed, 12 Apr 2017 09:27:20 +0200 Mattia Rizzolo wrote: >> On Wed, Apr 12, 2017 at 12:55:35PM +0530, Prabhu Ramachandran wrote: >> > I am afraid I don't exactly know what to do or have the bandwidth for >> > stepping >> > in as a maintainer. However, Kumar Appaiah (CC'd) said that he would be >> able to >> > help. >> >> Well, techinically you are already the maintainer. From the current >> package: >> >> Source: ygl >> Priority: extra >> Maintainer: Prabhu Ramachandran Uploaders: >> Ramakrishnan Muthukrishnan >> >> >> In that case, probably this package should be orphaned instead? >> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#orphaning > > Since this package was last uploaded in 2009 (~13 years ago) and the > maintainer > stated that they have no bandwidth to keep maintaining it plus Uploader has > retired, and this had 3 RC bugs opened (for a long time), I fixed the RC bugs, > and made the "Debian QA Team" as the package maintainer (effectively orphaning > it) and did a upload for this package. > The said bug that I am replying to right now has been open for 4+ years > (almost > 5) and hence from a pragmatic pov, I found it right to do. > > Unless Kumar has plans of stepping in, do you think we should close this bug > report too? > > Let me know. > > Regards, > Nilesh
Bug#859279: Updating the ygl Uploaders list
On 4/12/17 6:17 PM, Kumar Appaiah wrote: > On Wed, Apr 12, 2017 at 09:27:20AM +0200, Mattia Rizzolo wrote: >> On Wed, Apr 12, 2017 at 12:55:35PM +0530, Prabhu Ramachandran wrote: >>> I am afraid I don't exactly know what to do or have the bandwidth for >>> stepping >>> in as a maintainer. However, Kumar Appaiah (CC'd) said that he would be >>> able to >>> help. >> >> Well, techinically you are already the maintainer. From the current >> package: >> >> Source: ygl >> Priority: extra >> Maintainer: Prabhu Ramachandran <pra...@aero.iitb.ac.in> >> Uploaders: Ramakrishnan Muthukrishnan <rkrish...@debian.org> >> >> >> In that case, probably this package should be orphaned instead? >> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#orphaning > > I'm Prabhu's co-worker. I can co-maintain it with him. > > Thanks. Thank you Kumar! Regards, Prabhu
Bug#859279: Updating the ygl Uploaders list
Hi Mattia, I am afraid I don't exactly know what to do or have the bandwidth for stepping in as a maintainer. However, Kumar Appaiah (CC'd) said that he would be able to help. Thank you! Regards, Prabhu Ramachandran On 4/1/17 11:01 PM, Mattia Rizzolo wrote: > Source: ygl > Version: 4.2e-4 > Severity: minor > User: m...@qa.debian.org > Usertags: mia-teammaint > > Ramakrishnan Muthukrishnan <rkrish...@debian.org> has retired, so can't work > on > the ygl package anymore (at least with this address). > > We are tracking their status in the MIA team and would like to ask you > to remove them from the Uploaders list of the package so we can close > that part of the file. > > (If the person is listed as Maintainer, what we are asking is to please > step in as a new maintainer.) > > Thanks. >
Bug#499580: mayavi2: rendering issues
Varun Hiremath wrote: http://bugs.freedesktop.org/show_bug.cgi?id=16072 Bingo! I have Intel GM965/GL960 graphics card and I get the exact same error when I run: [...] I am using xserver-xorg-core 1.4.2 and libgl1-mesa-dri 7.0.3. The versions that seem to fix this problem -- xserver 1.5.0 and libgl1-mesa-dri 7.1 are both available in debian/experimental, though I haven't tried them yet. It would be really awesome if you could try those and see if it fixes your problem. In that case we could recommend to people to use that version when they report this problem -- many people suffer from this bug. Also, was some explorer function removed from mayavi2 in the new version? Not sure. Envisage plugins have changed so the explorer may not be exposed in the shell, however, I am not sure where the explorer is in the 3.x code base or if it works at all. That was a Pyface/traits package that I did not write... :( Okay, thanks. Should I ask on enthought-dev? Yes, don't tag the message to be mayavi specific if not it could fall through the cracks. Thanks! cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481839: mayavi2: raises exception when the user drags items in the MayaVi pane
Hi, This bug is fixed with the latest version (3.0.3) and with trunk as well. I cannot reproduce it with these versions. cheers, -- Prabhu Ramachandran http://www.aero.iitb.ac.in/~prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489781: mayavi2: Mayavi2 cannot open files on UTF-8 paths with accents
1) #489781: mayavi2: Mayavi2 cannot open files on UTF-8 paths with accents This is a pyface bug in branches. The bug does not exist in the upcoming 3.0 ETS version. I've reported this to the other developers to see if the 2.x branch can also be fixed. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489781: Debian Bug number 466711/489781
Hi, I'd like to test a fix for these bugs. Could you find the file called enthought/pyface/file_dialog.py (the same one you found the error in). Edit that file and replace the line 118 in the following: 117 # Get the path of the chosen directory. 118 self.path = str(self.control.GetPath()) with the following: 118 self.path = self.control.GetPath() i.e. remove the str call and see if that works for you. If it does I'll make the change to the branches as well and the bug may be closed as far as upstream is concerned. Thanks. cheers, -- Prabhu Ramachandran http://www.aero.iitb.ac.in/~prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487853: Fixed in branch and trunk
Hi, This bug is now fixed in trunk and branches. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478359: [Enthought-dev] Can Mayavi2 process multiblock plot3d data?
Kun. Qu wrote: I made a xyz file and q file in format of binary stream. They could be well displayed in Tecplot. But Mayavi2 can not display them. I had to save the multiblock data into several single block data. Then they could be loaded into mayavi2 as seperated plot3d sources. Any one may tell me where I can find how Mayavi2 process multiblock plot3d data? I just added a SelectOutput filter that lets you choose among the available outputs of a given source/filter. This is a simple solution that should let you choose which block to view. Here is an example from the data that Francesco reported here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478359 mayavi2 -p tiny.xyz -q tiny.q -f SelectOutput -m Outline -m Surface Click on the SelectOutput and select the output index of the data to use. You should be able to change the block. Add any number of these filters to the reader to choose whichever you want. The more complex feature request that Francesco requested is more work than I have time for now. I've checked this into the 2.1.2 branch in addition to trunk. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478844: [Python-apps-team] Bug#478844: mayavi2: segfaults or corrupts memory after some operations
Prabhu Ramachandran wrote: Francesco Poli wrote: then left-click on the (now childless) Modules entry and choose Visualize - Modules - ContourGridPlane from menus: * TVTK Scene 1 * PLOT3D:tiny.xyz, tiny.q * Modules * Surface * PLOT3D:tiny.xyz, tiny.q * Modules * ContourGridPlane At this point, as soon as I left-click on the ContourGridPlane module, I get a debugger window (see attached screenshot inspector.png) and cannot see any ContourGridPlane properties in the MayaVi object editor pane... OK, this is a bug that we are aware of but will take a little while to get sorted out. Thanks for the report though. I think I've found the problem and fixed it in the enthought.traits.ui.wx_2.0.5 branch that I just made. The problem in your case is that there is only one value of the scalar, so the high and low limits are the same leading to the floating point division error. Here is a patch you need to make to enthought/traits/ui/wx/range_editor.py (where it is installed) alternatively get this from the branch. The bug should therefore be closed as far as upstream is concerned. Varun already filed a ticket for improving the multi-block support which we'll get to later. cheers, prabhu Index: enthought/traits/ui/wx/range_editor.py === --- enthought/traits/ui/wx/range_editor.py (revision 18680) +++ enthought/traits/ui/wx/range_editor.py (working copy) @@ -515,7 +515,10 @@ except: fvalue_text = '' fvalue = low -ivalue = int( (float( fvalue - low ) / (high - low)) * 1 ) +if high low: +ivalue = int( (float( fvalue - low ) / (high - low)) * 1 ) +else: +ivalue = low # Lower limit label: label_lo = wx.StaticText( panel, -1, '99' ) @@ -648,7 +651,10 @@ self._set_format() self.control.label_lo.SetLabel( self._format % low ) self.control.label_hi.SetLabel( self._format % high ) -ivalue = int( (float( value - low ) / (high - low)) * 1.0 ) +if high low: +ivalue = int( (float( value - low ) / (high - low)) * 1 ) +else: +ivalue = low self.control.slider.SetValue( ivalue ) text = self._format % self.value self.control.text.SetValue( text )
Bug#478359: [Python-apps-team] Bug#478359: mayavi2: fails to read blocks other than the first, in multiblock PLOT3D files
Francesco Poli wrote: On Mon, 05 May 2008 21:38:45 +0530 Prabhu Ramachandran wrote: Mayavi2's current plot3d support is very basic and does not support any multi-block data. Well, I would say it supports it partially, in the sense that it reads multi-block data, but is only able to load the first block... That is correct. It is actually easy to let a user view a single block at a time since all of the outputs are already setup. I have to think more about how to do this better. OK, let's tell the truth, the whole truth, and nothing but the truth! [...] Thanks for the detailed feature description you need. [...] I am aware that the above could be tricky and burdensome to implement. If it turns out to be really too hard (even for visualization gurus like you!), my original request is an second-choice simpler approach. I'll repeat it here, just to be sure what I'm referring to is clear enough: This is useful. Varun, would it be possible to file this as a ticket please so we don't miss it. regards, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478844: [Python-apps-team] Bug#478844: mayavi2: segfaults or corrupts memory after some operations
Francesco Poli wrote: then left-click on the (now childless) Modules entry and choose Visualize - Modules - ContourGridPlane from menus: * TVTK Scene 1 * PLOT3D:tiny.xyz, tiny.q * Modules * Surface * PLOT3D:tiny.xyz, tiny.q * Modules * ContourGridPlane At this point, as soon as I left-click on the ContourGridPlane module, I get a debugger window (see attached screenshot inspector.png) and cannot see any ContourGridPlane properties in the MayaVi object editor pane... OK, this is a bug that we are aware of but will take a little while to get sorted out. Thanks for the report though. Unfortunately, I didn't manage to find the time to investigate further, that's why I decided to take a screenshot. No problem. The bug report is useful enough. Please note that ContourGridPlane seems to work as expected, if I start mayavi2 and avoid copying/pasting data sources, that is to say as in: OK. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478359: [Python-apps-team] Bug#478359: mayavi2: fails to read blocks other than the first, in multiblock PLOT3D files
Hi Varun and Francesco, Varun Hiremath wrote: I'm unable to read any block, except the first, in multiblock PLOT3D files. I can reproduce this bug with any multiblock PLOT3D file having more than one block. For instance we can consider the test case I prepared for bug #400406 (see [1] and [2]). Mayavi2's current plot3d support is very basic and does not support any multi-block data. This is a feature request and I would certainly appreciate it if you filed a ticket on the trac instance. [2] http://bugs.debian.org/cgi-bin/bugreport.cgi/vtk-multiblockPLOT3D-bug-test.tar.gz?bug=400406;msg=5;att=1 The test data is useful thanks. I'll keep a copy just so it can be used when I get to implementing the multi block support. OK, back to the PLOT3DReader tab: where's the option to select which grid blocks I want to load?!? I really cannot find it... Because it isn't implemented yet. :( I would like to have a means to decide which grid blocks will be loaded (e.g.: I want to load block 1, 2, and 4, but not the remaining two), so that a number of PLOT3D:tiny.xyz, tiny.q objects are automatically created, each one corresponding to one of the requested grid blocks (e.g.: three objects are created, corresponding to blocks 1, 2, and 4). The trouble with this approach is that it breaks down when you have 100 blocks. How do you view 100 of them? Anyway, this is something that would require some thought and work. Please note that this decision may be taken only after PLOT3D properties (such as Binary file, Has byte count, and so forth) have been specified, or otherwise the total number of blocks present in the PLOT3D file will not be computed correctly... Correct. Thanks for this detailed report. It looks more like a wishlist bug. I'm forwarding this upstream. Yes, that is correct. If you can add a ticket on the trac interface here, http://svn.enthought.com/enthought/ that would be great, if not I can add it (just let me know either way). Thanks. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478844: [Python-apps-team] Bug#478844: mayavi2: segfaults or corrupts memory after some operations
Hi Francesco, Varun Hiremath wrote: Hi Prabhu and Gael, I got one more bug report, could you please check: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478844 Any idea what is going on here? There have been some issues with mayavi2 in Debian after it was rebuilt with python 2.5 Any help would be appreciated. This is a problem with the binary reader in VTK. If you comment out all the settings you initialize in the list_plot3d.py you'll get garbage results and it looks like my hooking up the results of this entire process breaks things with the rest of the pipeline. Almost always segfaults are due to VTK related issues. I'll look at doing one of the following, either popping up a UI so you can set the properties before the files is loaded or looking at the error code to defer creation of the property. This is a bug. Thanks for reporting it. Hopefully I'll fix it soon. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478844: [Python-apps-team] Bug#478844: mayavi2: segfaults or corrupts memory after some operations
Francesco Poli wrote: On Thu, 1 May 2008 17:15:38 +0200 Francesco Poli wrote: On Thu, 1 May 2008 20:00:18 +0530 Varun Hiremath wrote: [...] Boom! Memory corruption! Strange, I am not able to reproduce this bug also on amd64 machine. You lucky man! ;-) I followed the same steps and I could copy/paste without any errors. If you don't believe me please see this screenshot: http://people.debian.org/~varun/misc/mayavi2_amd64.png I believe you! :) Little update: while doing other tests (that resulted in another bug report #478880...), I could successfully copy and paste the data source item. Well, I didn't follow the same exact sequence of operations, as described in the present bug report, but anyway, I could perform the operation that previously led to a segfault or a memory corruption issue. Your transparency issue is a bug in the Intel 965GM graphics card, which I suspect you have. See this thread: http://thread.gmane.org/gmane.comp.python.enthought.devel/13992/focus=14118 I think I've fixed the plot3d reader crash. I'll mail you about that shortly. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478844: [Python-apps-team] Bug#478844: mayavi2: segfaults or corrupts memory after some operations
Francesco Poli wrote:
[...]
Boom! Memory corruption!
Strange, I am not able to reproduce this bug also on amd64 machine.
You lucky man! ;-)
On my Mac (which is all I have access to on my vacation), I was able
to reproduce the problem nicely thank to the data that Francesco has
provided. I think I have a fix. Can you replace your copy of the
PLOT3DReader in the sources directory of your installed mayavi2 with the
attached and try again?
What this does is to pop up a UI as soon as the reader is initialized
and before the files are read giving you a chance to set the properties.
With that I am able to reliably open up your data files. If not it
tries to be graceful but can die if fed enough poison and this is solely
due to the VTK reader not behaving correctly. There is little I can do
about that.
Please try this and let me know that it works and I'll check it in to
both the branches and trunk.
Thanks for the bug reports and patience.
regards,
prabhu
A PLOT3D file reader. This reader does not support a timeseries of
files.
# Author: Prabhu Ramachandran [EMAIL PROTECTED]
# Copyright (c) 2007, Enthought, Inc.
# License: BSD Style.
# Standard library imports.
from os.path import basename, isfile
# Enthought library imports.
from enthought.traits.api import Trait, Instance, Str, TraitPrefixMap, Button
from enthought.traits.ui.api import View, Group, Item, FileEditor
from enthought.tvtk.api import tvtk
from enthought.persistence.state_pickler import set_state
from enthought.persistence.file_path import FilePath
# Local imports.
from enthought.mayavi.core.source import Source
from enthought.mayavi.core.common import handle_children_state, error
# `PLOT3DReader` class
class PLOT3DReader(Source):
A PLOT3D file reader. This reader does not support a
timeseries of files.
# The version of this class. Used for persistence.
__version__ = 0
# XYZ file name
xyz_file_name = Str('', desc='the XYZ file')
# The (optional) Q file.
q_file_name = Str('', desc='the Q file')
# The active scalar name.
scalars_name = Trait('density',
TraitPrefixMap({'density': 100,
'pressure':110,
'temperature': 120,
'enthalpy': 130,
'internal energy': 140,
'kinetic energy': 144,
'velocity magnitude': 153,
'stagnation energy': 163,
'entropy': 170,
'swirl': 184}),
desc='scalar data attribute to show')
# The active vector name.
vectors_name = Trait('momentum',
TraitPrefixMap({'velocity': 200,
'vorticity': 201,
'momentum': 202,
'pressure gradient': 210}),
desc='vector data attribute to show')
# The VTK data file reader.
reader = Instance(tvtk.PLOT3DReader, args=(), allow_none=False)
# View related code.
update_reader = Button('Update Reader')
# Our view.
view = View(Group(Item('xyz_file_name', editor=FileEditor()),
Item('q_file_name', editor=FileEditor()),
Item(name='scalars_name',
enabled_when='len(object.q_file_name) 0'),
Item(name='vectors_name',
enabled_when='len(object.q_file_name)0'),
Item(name='update_reader'),
label='Reader',
),
Group(Item(name='reader', style='custom',
resizable=True),
show_labels=False,
label='PLOT3DReader'
),
resizable=True)
# Private traits.
# The current file paths. This is not meant to be touched by the
# user.
xyz_file_path = Instance(FilePath, args=(), desc='the current XYZ file
path')
q_file_path = Instance(FilePath, args=(), desc='the current Q file path')
##
# `object` interface
##
def __get_pure_state__(self):
d = super(PLOT3DReader, self).__get_pure_state__()
# These traits are dynamically created.
for name in ('scalars_name
Bug#478960: mayavi2: interpolation produces fake transparency effects
Hi, This also seems like an artifact of the Intel 965 driver bug. I can't reproduce the problem on my mac (which is what I have ATM), I can test it on my ubuntu machines next week but am pretty sure none of them will display the problem. cheers, prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291438: tetex-bin: dvipdfm segfaults when used with hyperref and hypertex
Hilmar == Hilmar Preusse [EMAIL PROTECTED] writes: Hilmar On 20.01.05 Prabhu Ramachandran ([EMAIL PROTECTED]) Hilmar wrote: Hi, dvipdfm segfaults on the following trivial LaTeX file. Hilmar The upstrean author meanwhile provided a patch for the Hilmar problem. I've created a fixed binary sitting on [1] for Hilmar i386. Would you be so kind to download and test it, if Hilmar you're still using teTeX? It was just derived from the Hilmar binaries of tetex-bin however the dvipdfm binary of teTeX Hilmar 2.0 does not differ from that in 3.0 ... well except, that Hilmar it is dynamically linked against libkpathsea.so.4 and some Hilmar other more recent libs from unstable. :-| Thanks for the email! I downloaded the package (dvipdfm.zip) and can confirm that it solves the problem -- I don't get a segfault anymore and the output looks OK. Thanks! regards, -- Prabhu Ramachandran http://www.aero.iitb.ac.in/~prabhu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291438: tetex-bin: dvipdfm segfaults when used with hyperref and hypertex
FK == Frank Küster [EMAIL PROTECTED] writes: FK Prabhu Ramachandran [EMAIL PROTECTED] wrote: OK, I've found the bug. Basically, the asn_date function in texk/dvipdfm/pdfdoc.c was writing to a string but did not allocate enough memory for the string before writing to it. Attached is a trivial patch for the file texk/dvipdfm/pdfdoc.c. FK [...] - static char date_string[24]; + static char date_string[32]; FK First of all, I must admit that I don't have much experience FK with C. But still I have some critical remarks to this: FK - We couldn't reproduce the bug here, and it is in a function FK that works on time data. Could it be that it is your FK (Prabhu's) timezone or locale setting that is necessary to FK reproduce the segfault? I guess so, I provided some data from gdb in my reply to your email. I'm at GMT+0530 hours. FK - Wouldn't it be better to find some clever way do dynamically FK allocate just as much memory for the date_string array as is FK needed? Especially when it is about timezone or locale, I FK suspect that sooner or later there will be one where even FK the 32 chars won't be sufficient. Not sure about that. I don't deal with time in C so am not sure what the best approach is. However, I don't think timezones are going to change in our time scales. :) So I think coming up with a fix to handle all timezones should work fine for the future. I guess Mark will know better. cheers, prabhu
Bug#291438: tetex-bin: dvipdfm segfaults when used with hyperref and hypertex
FK == Frank Küster [EMAIL PROTECTED] writes:
I will try it in a clean sarge environment soon.
No problems on sid (powerpc) with tetex-bin_2.0.2-26.
FK I also did not get a segfault in my i386 sarge chroot. I'm
FK helpless - how can one debug this? The only idea I have, since
FK Prabhu seems to be familiar with gdb, would be to recompile
FK dvipdfm without stripping and optimising. I think this should
FK be easily possible in the following way:
[...]
Sorry for taking so long to respond. I tried this on yet another
fresh install of sarge (on an AMD Sempron) with tetex-bin version
2.0.2-25 and got the segmentation fault there too!
Anyway, I compiled dvipdfm without optimizations as you suggested.
Here are some results.
(gdb) r -o /tmp/test.pdf /tmp/test.dvi
Starting program: /tmp/tetex-bin-2.0.2/texk/dvipdfm/dvipdfm.exe -o
/tmp/test.pdf /tmp/test.dvi
/tmp/test.dvi - /tmp/test.pdf
[1]
Program received signal SIGSEGV, Segmentation fault.
0x401103c2 in memcmp () from /lib/libc.so.6
(gdb) bt
#0 0x401103c2 in memcmp () from /lib/libc.so.6
#1 0x0804e0be in cmp_dest (d1=0x812c700, d2=0x812c70c) at pdfdoc.c:597
#2 0x400c4120 in msort_with_tmp () from /lib/libc.so.6
#3 0x400c4360 in qsort () from /lib/libc.so.6
#4 0x0804e3a0 in finish_dests_tree () at pdfdoc.c:651
#5 0x0804f46f in pdf_doc_close () at pdfdoc.c:1048
#6 0x08052669 in dvi_close () at dvi.c:1205
#7 0x08065666 in main (argc=3, argv=0xb7f8) at dvipdfm.c:665
(gdb) up
#1 0x0804e0be in cmp_dest (d1=0x812c700, d2=0x812c70c) at pdfdoc.c:597
597 if ((tmp = memcmp (((dest_entry *) d1) - name, ((dest_entry *) d2)
(gdb) list
592 {
593 unsigned length;
594 int tmp;
595 length = MIN (((dest_entry *) d1) - length, ((dest_entry *) d2) -
596 length);
597 if ((tmp = memcmp (((dest_entry *) d1) - name, ((dest_entry *) d2)
598 - name, length)) != 0)
599 return tmp;
600 if (((dest_entry *) d1) - length == ((dest_entry *) d2) - length)
601 return 0;
(gdb) print length
$1 = 135461632
That looks wrong? I did not go much farther. I'll try and spend more
time on it in a short while and get back to you if I see any light.
I also notice that you seem to refer to tetex-bin-2.0.2-26 where as I
am using 2.0.2-25. Thinking that it would make a difference, I
downloaded the 2.0.2-26 deb from unstable, extracted its dvipdfm
binary and had the same problem with that too (on two different
machines).
Just to eliminate one possibility I've attached the test.dvi file that
was produced via latex test.tex. This one segfaults for me with
$ dvipdfm --version
dvipdfm, version 0.13.2c, Copyright (C) 1998, 1999 by Mark A. Wicks
$ dvipdfm test.dvi
test.dvi - test.pdf
[1]Segmentation fault
Atleast if the dvi file works for you we know its a dvipdfm specific
bug. Of course, the dvi file renders just fine on xdvi and converts
to PS and PDF just fine when I use dvips or dvipdf. dvipdfm alone
seems to run into this problem.
Thanks.
cheers,
prabhu
test.dvi
Description: Binary data
Bug#291438: tetex-bin: dvipdfm segfaults when used with hyperref and hypertex
FK == Frank Küster [EMAIL PROTECTED] writes:
FK [EMAIL PROTECTED] (Uwe Steinmann) wrote:
On Fri, Jan 21, 2005 at 03:22:39PM +0100, Frank Küster wrote:
Prabhu Ramachandran [EMAIL PROTECTED] wrote:
Package: tetex-bin Version: 2.0.2-25 Severity: important
dvipdfm segfaults on the following trivial LaTeX file.
FK I also did not get a segfault in my i386 sarge chroot. I'm
FK helpless - how can one debug this? The only idea I have, since
FK Prabhu seems to be familiar with gdb, would be to recompile
FK dvipdfm without stripping and optimising. I think this should
FK be easily possible in the following way:
[...]
OK, I've found the bug. Basically, the asn_date function in
texk/dvipdfm/pdfdoc.c was writing to a string but did not allocate
enough memory for the string before writing to it. Attached is a
trivial patch for the file texk/dvipdfm/pdfdoc.c.
With this patch dvipdfm works fine for me and does not segfault
anymore.
HTH.
prabhu
--- pdfdoc.c.orig 2005-01-22 16:12:30.0 +0530
+++ pdfdoc.c2005-01-22 16:12:38.0 +0530
@@ -239,7 +239,7 @@
#define timezone 0l
#endif /* TM_GM_TOFF */
#endif /* HAVE_TIMEZONE */
- static char date_string[24];
+ static char date_string[32];
time_t current_time;
struct tm *bd_time;
if (debug) {
Bug#291438: tetex-bin: dvipdfm segfaults when used with hyperref and hypertex
Package: tetex-bin
Version: 2.0.2-25
Severity: important
dvipdfm segfaults on the following trivial LaTeX file.
%--
% test.tex
\documentclass[12pt,a4paper]{article}
\usepackage[hypertex]{hyperref}
\begin{document}
This is a simple test.
\end{document}
%--
If you compile the file and run dvipdfm on the resulting dvi file
you'll get a segfault as shown below.
$ latex test.tex
[...]
$ dvipdfm test.dvi
test.dvi - test.pdf
[1]Segmentation fault
Enclosed below is the test.log file for more details on my LaTeX
environment.
# --
This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5) (format=latex 2005.1.18) 21
JAN 2005 00:25
entering extended mode
**test.tex
(./test.tex
LaTeX2e 2001/06/01
Babel v3.7h and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size12.clo
File: size12.clo 2001/04/21 v1.4e Standard LaTeX file (size option)
)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
)
(/usr/share/texmf/tex/latex/hyperref/hyperref.sty
Package: hyperref 2003/01/22 v6.73n Hypertext links for LaTeX
(/usr/share/texmf/tex/latex/graphics/keyval.sty
Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
[EMAIL PROTECTED]@=\toks14
)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
(/usr/share/texmf/tex/latex/hyperref/pd1enc.def
File: pd1enc.def 2003/01/22 v6.73n Hyperref: PDFDocEncoding definition (HO)
)
(/usr/share/texmf/tex/latex/config/hyperref.cfg
File: hyperref.cfg 2002/06/06 v1.2 hyperref configuration of TeXLive and teTeX
)
Package hyperref Info: Hyper figures OFF on input line 1792.
Package hyperref Info: Link nesting OFF on input line 1797.
Package hyperref Info: Hyper index ON on input line 1800.
Package hyperref Info: Plain pages ON on input line 1805.
Package hyperref Info: Backreferencing OFF on input line 1812.
Implicit mode ON; LaTeX internals redefined
Package hyperref Info: Bookmarks ON on input line 1916.
(/usr/share/texmf/tex/latex/misc/url.sty
\Urlmuskip=\muskip10
Package: url 1999/03/28 ver 1.5x Verb mode for urls, etc.
)
LaTeX Info: Redefining \url on input line 2055.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Package hyperref Info: Hyper figures OFF on input line 2513.
Package hyperref Info: Link nesting OFF on input line 2518.
Package hyperref Info: Hyper index ON on input line 2521.
Package hyperref Info: backreferencing OFF on input line 2528.
Package hyperref Info: Link coloring OFF on input line 2533.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
)
*hyperref using driver hypertex*
(/usr/share/texmf/tex/latex/hyperref/hypertex.def
File: hypertex.def 2003/01/22 v6.73n Hyperref driver for HyperTeX specials
)
No file test.aux.
\openout1 = `test.aux'.
LaTeX Font Info:Checking defaults for OML/cmm/m/it on input line 3.
LaTeX Font Info:... okay on input line 3.
LaTeX Font Info:Checking defaults for T1/cmr/m/n on input line 3.
LaTeX Font Info:... okay on input line 3.
LaTeX Font Info:Checking defaults for OT1/cmr/m/n on input line 3.
LaTeX Font Info:... okay on input line 3.
LaTeX Font Info:Checking defaults for OMS/cmsy/m/n on input line 3.
LaTeX Font Info:... okay on input line 3.
LaTeX Font Info:Checking defaults for OMX/cmex/m/n on input line 3.
LaTeX Font Info:... okay on input line 3.
LaTeX Font Info:Checking defaults for U/cmr/m/n on input line 3.
LaTeX Font Info:... okay on input line 3.
LaTeX Font Info:Checking defaults for PD1/pdf/m/n on input line 3.
LaTeX Font Info:... okay on input line 3.
Package hyperref Info: Link coloring OFF on input line 3.
(/usr/share/texmf/tex/latex/hyperref/nameref.sty
Package: nameref 2001/01/27 v2.19 Cross-referencing by name of section
[EMAIL PROTECTED]@level=\count92
)
LaTeX Info: Redefining \ref on input line 3.
LaTeX Info: Redefining \pageref on input line 3.
[1
] (./test.aux) )
Here is how much of TeX's memory you used:
1699 strings out of 95732
23234 string characters out of 1194482
63852 words of memory out of 101
4759 multiletter control sequences out of 1+5
3938 words of font info for 15 fonts, out of 50 for 1000
14 hyphenation exceptions out of 1000
25i,4n,21p,162b,119s stack positions out of 1500i,500n,5000p,20b,5000s
Output written on test.dvi (1 page, 328 bytes).
# --
A gdb backtrace on the segmentation fault seemed useless since none of
the debugging symbols are available in my build. An ltrace on dvipdfm
provides this output in
