Greyscale bug?

Hello,
Don't knnow if this is new to iPhoto '08 or not, but I can't import a greyscale picture.
I have a greyscale jpeg that won't import: it gives a black image in iPhoto, with a strange very dark and partly transparent rendition of the image when I double-click on it.
If I save it in a RGB format jpeg (image still is B&W, but the format is rgb), it works just fine in iPhoto. Save that image in greyscale again and it won't import.
What's up with that???
Loa

Loa:
That's been a bug since iPhoto 6. You'll have to scan the photos as color and use them that way. Be sure to report that bug to Apple at http://www.apple.com/feedback/iphoto.html.
Do you Twango?
TIP: For insurance against the iPhoto database corruption that many users have experienced I recommend making a backup copy of the Library6.iPhoto database file and keep it current. If problems crop up where iPhoto suddenly can't see any photos or thinks there are no photos in the library, replacing the working Library6.iPhoto file with the backup will often get the library back. By keeping it current I mean backup after each import and/or any serious editing or work on books, slideshows, calendars, cards, etc. That insures that if a problem pops up and you do need to replace the database file, you'll retain all those efforts. It doesn't take long to make the backup and it's good insurance.
I've written an Automator workflow application (requires Tiger), iPhoto dB File Backup, that will copy the selected Library6.iPhoto file from your iPhoto Library folder to the Pictures folder, replacing any previous version of it. It's compatible with iPhoto 08 libraries. You can download it at Toad's Cellar. Be sure to read the Read Me pdf file.

Similar Messages

Really bad banding and artifacts in 16-bit layered greyscale file. Bad banding is retained when converted to 8-bit with No flattening. Flatten 16-bit image and banding and artifacts disappear even with no dither or noise layer. Is this a known bug?

Has anyone else experienced this?
I thought it was a monitor problem at first, but I'm using a 10-bit per channel Eizo. It seems to be a Photoshop bug based on many layers interacting with each other. When I flatten everything is fine. But I need to work on this image with layers and decent fidelity. Interestingly when I convert to 8-bit without flattening (and utilising the dither function to potentially reduce banding even further), it uses the terrible artifact laden/banding to do the conversion even though when I zoom into 1:1 in my 16-bit document it looks fine. But 50% or 25% zoom I suddenly get these awful artifacts.
Here's some screenshots to clarify. Please note I've used Photoshop for 24 years so I'm no slouch but this is the first time I've seen this. The problem is I need to do some subtle airbrush and texture work on this and it's almost unusable unless I flatten (please note, it does the same in the original 8-bit file and just to say I Gaussian-Blurred every layer with a 30px radius after converting to 16-bit so the there's no longer any 8-bit information in there or reasons for banding/artifacts). I can only think it is some of bug in Photoshop's layering engine.
Has anyone seen this before - dealt with this before?
Thanks in advance.
Not sure these embedded images will work.
8% zoomed - see all the strange banding and triangular artifacts
<a href="http://imgur.com/izrGuia"><img src="http://i.imgur.com/izrGuia.png" title="source: imgur.com" /></a>
Flattened view - all smooth:
<a href="http://imgur.com/Pn35IAK"><img src="http://i.imgur.com/Pn35IAK.png" title="source: imgur.com" /></a>
50% zoom, still there:
<a href="http://imgur.com/Z207hFd"><img src="http://i.imgur.com/Z207hFd.png" title="source: imgur.com" /></a>
100% artifacts disappear:
<a href="http://imgur.com/6aGOz0V"><img src="http://i.imgur.com/6aGOz0V.png" title="source: imgur.com" /></a>
100% 16-bit layered
<a href="http://imgur.com/0XJfe5e"><img src="http://i.imgur.com/0XJfe5e.png" title="source: imgur.com" /></a>
and finally 8-bit layered converted from 16-bit with dither.
<a href="http://imgur.com/PSxiu43"><img src="http://i.imgur.com/PSxiu43.png" title="source: imgur.com" /></a>
help!

I can't speak to why, perhaps someone more knowledgeable than I can speak to that. But if it only happens at certain views then it's purely a display issue; it won't happen in print or when you downsample to display size. Such banding issues have always disappeared for me when I output to 8 bit.
I'd assume that it's because of your monitor; it can't display all the colors and when zoomed out there's too wide of a range in a small area so banding occurs. But that's just my guess.

How do I paint accurate grey levels between 0-254 in an alpha or a greyscale image? Seems impossible ... Works in 5.5 .. not in CC. Bug?

So here's the thing . I need to be able to assign accurate shades of grey in an alpha channel as our code takes the value (between 0-244) and uses it to do its thing. I assumed this would be easy .. just choose your colour and paint .. but not so.
In an alpha channel, or even in a greyscale image, make a selection and fill it with RGB 6,6,6. Since there doesn't seem to be a way to get a greyscale pallette or input the value for Alpha this is th eonly way I can see to do it.
Now, using the info panel, check that it is indeed RGB 6,6,6. It is.
Now, make another selection and fill it with RGB 7,7,7. Check this with the info panel and ... its 6,6,6.
OK so now use levels or brightness to try to shift that 6,6,6 upto 7,7,7 ... check it with the eyedropper color sampler tool .
What you'll find is that the RGB value will go from 6,6,6 .. to 8,8,8 to 10,10,10 it's impossible to make it 7,7,7 or 9,9,9. Theres a whole bunch of other values that are also impossible.
If you do the above in any of the RGB channels themselves it will work fine .. its just the Alpha and in a greyscale image.
On a similar vein, on a regular layer, fill an area with you RGB 7,7,7, copy it and paste it into your alpha. Looks fine .. until you use levels to increase the contrast and you'll find that what was 7,7,7 is now a noise filled mixture of, I assume, 6,6,6 and 8,8,8.
( NB. As a note the above also happened in CS5 but in an old version of Photoshop 5.5 it works perfectly .. I can give the RGB 7,7,7 and the value thats painted is 7,7,7. Bring it into CC and its fine. So its just the creation of tones in CC that is wrong.
Also, it works fine if you edit the individual RGB channels .. you can get 6,6,6 AND 7,7,7 .. but as soon as you copy and paste it into the alpha . .the 7,7,7 reverts to 6,6,6 )
So
Q1 .. what am I doing wrong?
Q2 .. if 8bit alphas and greyscale images can have values ranging from 0-254 .. then how do I define the value I actually want? I can't use the K value as that's only a percentage so has fewer increments and there isn't a separate input for alpha value.
Q3 .. or put it more simply .. how do I set the grey value to a particular number, eg. 7
Thanks.
Pat
Message was edited by: Patrick Ward

Thanks Herbert. I'll have a good look at Photoline.
I don't know if these have anything to do with it but
the first is the color settings from CS5,
the second is the default from a demo install of CC14. I see the gamma tickbox but it doesn't refer to the alpha.
the thrid are the colour settings of PS 5.5. Note this is the one that gives the correct ( with respect to my expectations ) result

Acrobat stops working when multiple PDFs are opened together, is this a bug?

Not sure this is the correct thread but then none of the threads are obviously the correct place for this question. I am running W7 last updated a week ago so it should be running all the correct progs and drivers. Acrobat XI Pro is Version 11.0.10, I have thought about updating to DC but I'm about to transfer the progs to my portable as I travel widely and don't currently see the point.
I have just started to notice that if I drag a single file from file manager to an open Acrobat window it opens without error but when I highlight more than one file and drag them across they open, then while the final file is displaying itself on the screen Acrobat throws a wobbly and stops working. Is this a known bug? Happens every time I open 2 files. Windows has been restarted from scratch and it still happens. Happens whether I highlight the files in file manager then <right click> Open With Adobe Acrobat XI or whether I drag the files across to an open window. Happens whether Acrobat is already open or when it is closed. Happens with more than 2 files as well.
I have noticed that file manager does take a while to display a preview of the file when the preview pane is open and thought that it might be the preview pane that is causing problems. I then closed the preview pane and opened 3 files without a problem, then opened 8 files at the same time and the programme fell apart again. Could be to do with the Microsoft File Manager but I'm interested to know if this is a common problem or not? I did a search on file opening errors in the Acrobat forum without success so am assuming it is unusual.

Thanks, seems to solve some of the problem, perhaps I need to uncheck more in this dialogue box... May be 'a' correct answer but not the complete solution. Anyway if all I need to do is uncheck a choice in a dialogue box then it must be a bug or driver incompatability as there seems to be no reason why I shouldn't be able to use 2D graphics acceleration.
Works if you highlight several PDFs in File Manager and then right click and 'Open with Adobe Acrobat', the error still occurs if I drag these files into an open instance of Acrobat beyond two files. Also seems to be more of a problem if one of the files is a 'colour document ' or 'greyscale document' scanned by Acrobat itself.

REPORT: Bug in OS X's anti-aliasing w/ rotated screen

This is a fairly substantial bug. This may not be the ideal place to post it, but could someone tell me where to submit this so Apple will take notice?
A friend and I both have Mac Pros w/ ATI X1900 displays. This video card supports screen rotation in the OS X Displays control panel. So he went out and grabbed a rotating 1600x1200 Samsung (4:3) display to set next to his 30" Apple Cinema Display (both 1600 pixels tall, when the Samsung is in portrait orientation - a good match).
Have a look at the setup:
http://www.hubbuddy.com/downloads/dual/DSCN0914.jpg
He has his 'Font smoothing style' in the Appearances prefs pane set to "Medium - best for flat panel." This setting uses subpixeling, providing up to 3x the horizontal resolution of the screen's native pixel width. (More about sub-pixeling here: http://www.grc.com/cleartype.htm )
Sub-pixeling depends upon the orientation of the RGB elements of each sub-pixel cluster that makes up a pixel. When a screen is rotated 90-degrees, the RGB "stripes" run horizontal, not vertical. As can be seen from the below images, where the first image (ONE) shows the rotated Samsung and the second image (TWO) shows the standard orientation Apple Cinema 30", OS X's sub-pixeling does NOT take into account the new orientation of the sub-pixel clusters, resulting in a rather bold and crude rendering of text on the rotated first (ONE) image:
http://www.hubbuddy.com/downloads/dual/one.jpg
http://www.hubbuddy.com/downloads/dual/two.jpg
Apple needs to correct this so that people don't have to abandon sub-pixeling and use 'Standard' (greyscale) anti-aliasing. Microsoft takes sub-pixel cluster orientation into account with Windows Mobile (CE) on the Pocket PC's. Surely Apple can get this working with rotated screens under OS X.
Thanks. Where do I submit this?
bp

Digg this story...
http://www.digg.com/apple/OSX_supports_screen_rotation_but_its_rotated_anti_aliasing_isbroken
...to get the word out. (Just trying to get this addressed.)
blakespot

Aperture and greyscale tif scans

Hi,
I scanned my old black&white pics and manage them in Aperture. But when I want to use the repair tool Aperture turns my pic into a B&W negativ. I use Aperture 2.1. Does anybody has an ideas what is going on? Is it a bug?

Yes they are greyscale. But it just happen to the Tif I get from the Canon Scan software. Which is still PPC-version. Open the faulty image in Photoshop and save it as Tif again and the problem is gone. So I don't know exactly what is wrong. Theoretically Aperture should not have this problem.
Message was edited by: chiliego

Jpg greyscale file not importing

I wonder if there is a bug in the new iPhoto '09? I used to be able to import 8-bit greyscale images saved from Photoshop with an ICC profile; now I get a message that the file format is not supported. I also have noticed that at least one other such photo, previously imported into iPhoto, will not display. (In the past, the previews were always black, but double-clicking the preview would show the image as expected.)

That's too bad that grayscale is not supported. I have used grayscale primarily to save file size. I scan my kids school reports and their pencil drawings and import them. Since so many of Apple's customers are graphic designers, I'll bet many of us do the same thing. And, because of that, I'll bet it would be helpful to support CMYK, too.

Yet another bug in Photoshop CS3: Lab Colour Mode

Using Photoshop CS3 Standard (english) on Windows XP SP2, I cannot switch to Lab colour mode. Or rather, I can, but the image will turn completely black. In the channels palette in Lab mode, there are four channels: L, a, b, and Lab. The three single channels obviously contain the correct data, and I can select each one and the display will show the correct greyscale representations of the L channel, the a channel, and the b channel. But it won't show the colour image of all channels combined, i. e. the Lab image; this will appear simply black instead.
Fortunately, I still have Photoshop CS2 installed. So due to this and numerous other bugs (particularly the §@#!& printing) I am using Bridge 2.1 and ACR 4.1 but not Photoshop CS3. This application is just too buggy to get serious work done :(
-- Olaf

The exact same thing happened to me just 2 days ago. It was the first time I had ever tried LAB, in any version of PS, and all I got was the black box. I switched to my earlier version (PS7 in this case) and tried it, thinking that maybe my computer wouldn't support it for some reason, since it's several years old. PS7 displayed LAB just fine... I went back to CS3 (I had closed it down completely) and when it restarted - it LAB worked correctly, BUT all my preferences had been reset to default! So, I agree with the previous poster who commented that it may be a preferences thing. You should also check the color management settings in your earlier version & make sure the CS3 has the same settings. I have no idea if that made a difference or not, but I did notice that my CS3 didn't have the same color settings as PS7 did. Try resetting preferences to default, shutting down CS3 and restarting, and then check to see if CS3 will display LAB correctly.

Camera Raw CS6 produces damaged files when doing greyscale conversion

When attempting to save to JPEG from CS6 Camera Raw for Nikon NEF files (with the greyscale conversion checkbox checked), the resulting images are damaged: red hue output with scattered noise. See:
https://picasaweb.google.com/lh/photo/duJSMbdMd5VZLSQQy46hXb4WSo7wDW7hk8bkMgDW8HE?feat=dir ectlink
This has been observed on D90 and D600 NEF files, CS6 trial installation. Exporting the image to Photoshop main works, but is laborious for bulk conversions.
Is this a known bug?

theuns.verwoerd wrote:
Is this a known bug?
Yes, known issue...will be fixed. In the meantime the workaround is to process the images as sRGB (gamma 2.2) or ProPhoto RGB (gamma 1.8) and convert to grayscale in Photoshop.

Colour grads in greyscale images

I needed a black and white copy of this image, so I made a virtual copy and converted it to greyscale. I love the flexibility of the grayscale mixer, so and decided to darken the sky with a blue grad and then use the grayscale mix to adjust the level of the blue.
I know I could have done this with the brightness or exposure in the grad, but I wanted to drag the blues darker as I was not getting the results I wanted from the exposure / brightness.
I now have a colour black and white image!
Even if I start with the colour image and then manipulate the colour gradient and then make the image greyscale, the colour grad stays colour.
Any thoughts for how to work with colour grads in photos and then neediong to convert to black and white versions, cos mine is black and blue and white.
another "split toning" effect
Hamish

Any thoughts for how to work with colour grads in photos and then neediong to convert to black and white versions, cos mine is black and blue and white.
another "split toning" effect
Yes, it's split tone effect. Nevertheless, I bugged this "particular" behaviour a few months back, but was advised that it was as designed. However, the language used didn't exactly convince me that the respondent didn't agree with me that it's bug.
To be clear, adding a colour grad to a B&W image doesn't cause me any difficulties and an effect I use a lot. However, leaving the effects of a colour grad in play after converting to B&W is to my mind dumb in the extreme. I've seen reports on this forum of images were the original grad was quite subtle and therefore easily forgotten about. When the image was subsequently converted to B&W (usually as a VC) the colour comes through and confused the hell out of the user.

BUGS: Theme 17 Tabs

I've come across a couple of problems with theme 17 (Greyscale).
I started investigating a rendering problem with theme 17 tabs in Webkit-based browsers.
I haven't yet figured out why Webkit is computing the height of the tab <div>s differently to other browsers. Obviously happy to hear from anyone who's figured this out.
However the 2-level tab page template contains an HTML error in that the wrapper <div>s for the parent and child tabs are both assigned the id attribute value "t17Tabs", when ids must be unique within a document:
<div id="t17Tabs">#PARENT_TAB_CELLS#</div><div id="t17Tabs">#TAB_CELLS#</div>Themes normally use another "t17ChildTabs" or suchlike ids with 2-level tabs, but as well as being missing from the page template, there is no such selector referenced in the theme 17 CSS. This leads me to think that identical treatment of both tab levels is intended, and "t17Tabs" should be a class attribute not an id?
Edited by: fac586 on 04-Sep-2011 10:42
Removed link to example application as it is no longer relevant.

Finally found some time to look at this again.
1. The Webkit browser problem is due to the following CSS rule:
.t17CurrentTab, .t17Tab { display: -moz-inline-box; }which is in the main /theme_17/theme_3_1.css CSS file, and of course is only recognised by Mozilla browsers. The following rule is in the IE-only /theme_17/ie.css CSS file hidden from other browsers in a conditional comment so is only applied to IE.:
.t17CurrentTab { display: inline-block; }
.t17Tab { display: inline-block; }So the fix to display tabs properly in Safari and Chrome (and Opera for that matter) is to change the rule in theme_17/theme_3_1.css (or elsewhere) to:
.t17CurrentTab, .t17Tab {
display: -moz-inline-box;
display: inline-block;
}which works with all browsers as FF 3+ now also supports inline-block (and the original property still works in FF2). This also actually makes the IE-only CSS superfluous at the present time as the above are the only rules in it.
2. The duplicate t17Tabs ID issue obviously remains, so I've changed my local templates to have class="t17Tabs" instead and supplied the required CSS:
.t17Tabs {
border-bottom: 1px solid #000;
text-align: left;
white-space:nowrap;
}Edited by: fac586 on 04-Sep-2011 10:43
This was fixed as bug 8527710 in the APEX 3.2.1 patch set. However, this theme 17 "Greyscale" as replaced by a completely different theme 17 "Sapphire" in APEX 4.0, rendering this bug (and workaround) of historical interest only.

Index with "or" clause (BUG still exists?)

The change log for 2.3.10 mentions "Fixed a bug that caused incorrect query plans to be generated for predicates that used the "or" operator in conjunction with indexes [#15328]."
But looks like the Bug still exists.
I am listing the steps to-repro. Let me know if i have missed something (or if the bug needs to be fixed)
DATA
dbxml> openContainer test.dbxml
dbxml> getDocuments
2 documents found
dbxml> print
<node><value>a</value></node>
<node><value>b</value></node>
INDEX (just one string equality index on node "value")
dbxml> listIndexes
Index: unique-node-metadata-equality-string for node {http://www.sleepycat.com/2002/dbxml}:name
Index: node-element-equality-string for node {}:value
2 indexes found.
QUERY
setVerbose 2 2
preload test.dbxml
query 'let $temp := fn:compare("test", "test") = 0
let $results := for $i in collection("test.dbxml")
where ($temp or $i/node[value = ("a")])
return $i
return <out>{$temp}{$results}</out>'
When $temp is true i expected the result set to contain both the records, but that was not the case with the index. It works well when there is no index!
Result WITH INDEX
dbxml> print
<out>true<node><value>a</value></node></out>
Result WITHOUT INDEX
dbxml> print
<out>true<node><value>a</value></node><node><value>b</value></node></out>

Hi Vijay,
This is a completely different bug, relating to predicate expressions that do not examine nodes. Please try the following patch, to see if it fixes this bug for you:
--- dbxml-2.3.10-original/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-04-18 10:05:24.000000000 +0100
+++ dbxml-2.3.10/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-08-08 11:32:10.000000000 +0100
@@ -1566,11 +1572,12 @@
     else if(name == Or::name) {
          UnionQP *unionOp = new (&memMgr_) UnionQP(&memMgr_);
+          result.operation = unionOp;
          for(VectorOfASTNodes::iterator i = args.begin(); i != args.end(); ++i) {
               PathResult ret = generate(*i, ids);
               unionOp->addArg(ret.operation);
+               if(ret.operation == 0) result.operation = 0;
-          result.operation = unionOp;
     // These operators use the presence of the node arguments, not their valueJohn

Bug report follow-up

is there a way to follow-up on a bug report that i submitted? i have the bug number, but would like to see if the report was understood, filled out properly and determine the status of the bug report.
thanks,
doug

They comment on bugs if actions were taken. Otherwise - don't expect any feedback.

Solaris8 and 9 (possibly 7) /dev/poll driver bug report.

Hello,
I'd like to report a bug in the solaris 8 and 9 /dev/poll driver (poll(7d)).
As i do not have a support account with sun or anything like that, there
seems to be no other way to do that here (which is of course a very sad
thing).
Bug details:
The /dev/poll device provides an ioctl-request (DP_ISPOLLED) for checking
if a particular filedescriptor is currently in the set of monitored
filedescriptors for that particular /dev/poll fd set (open /dev/poll fd).
A quote from the documentation of the poll(7d) manual page taken from
Solaris9:
"DP_ISPOLLED ioctl allows you to query if a file descriptor is already in
the monitored set represented by fd. The fd field of the pollfd structure
indicates the file descriptor of interest. The DP_ISPOLLED ioctl returns 1
if the file descriptor is in the set. The events field contains the
currently polled events. The revents field contains 0. The ioctl returns 0
if the file descriptor is not in the set. The pollfd structure pointed by
pfd is not modified. The ioctl returns a -1 if the call fails."
It says that when you query for an filedescriptor which is currently being
monitored in the set, that it would return 1, and change the events field of
the pollfd structure to the events it's currently monitoring that fd for.
The revents field would be set to zero.
However the only thing which actually happens here, is that FD_ISPOLLED
returns 1 when the fd is in the set and 0 if not. When the fd is in the
set, when FD_ISPOLLED returns 1, the events field remains unmodified, but
the revents field gets changed.
A small sample code to illustrate:
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/devpoll.h>
main() {
struct pollfd a;
int dp_fd = open("/dev/poll", O_WRONLY);
a.fd = 0; /* stdin */
a.events = POLLIN; /* we monitor for readability, POLLIN=1 */
a.revents = 0;
write(dp_fd, &a, sizeof(a));
a.fd = 0;
a.events = 34; /* filled in with bogus number to show malfunctioning */
a.revents = 0;
printf("DP_ISPOLLED returns: %d\n", ioctl(dp_fd, DP_ISPOLLED, &a));
printf("a.fd=%d, a.events=%hd, a.revents=%hd\n", a.fd, a.events,
a.revents);
According to the documentation of /dev/poll and namely DP_ISPOLLED this
program is supposed to print the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=1, a.revents=0
However it prints the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=34, a.revents=1
You can take any number instead of '34' and it will simply remain untouched
after the DP_ISPOLLED ioctl-request.
I hope it's clear now that the solaris8 and solaris9 (and probably solaris7
with /dev/poll patch too) DP_ISPOLLED implementation is broken.
This bug is also easily illustrated by looking at the solaris8 kernel sourcecode:
<snippet osnet_volume/usr/src/uts/common/io/devpoll.c:dpioctl()>
case DP_ISPOLLED:
pollfd_t pollfd;
polldat_t *pdp;
if (pollfd.fd < 0) {
mutex_exit(&pcp->pc_lock);
break;
pdp = pcache_lookup_fd(pcp, pollfd.fd);
if ((pdp != NULL) && (pdp->pd_fd == pollfd.fd) &&
(pdp->pd_fp != NULL)) {
pollfd.revents = pdp->pd_events;
if (copyout(&pollfd, (caddr_t)arg,
sizeof(pollfd_t))) {
mutex_exit(&pcp->pc_lock);
DP_REFRELE(dpep);
return (set_errno(EFAULT));
*rvalp = 1;
</snippet>
its' clearly visible that the code writes the current monitored events to
the revents field:
'pollfd.revents = pdp->pd_events;'
and that it doesnt set revents to zero.
It's funny to see that this has been like this since Solaris8 (possibly 7). That means nobody ever used DP_ISPOLLED that way or people were simply to lazy to file a bug report.
Another funny thing related to this. is that Hewlett-Packard did seem to know about this. Since HP-UX11i version 1.6 they also support /dev/poll. From their manual page i ll quote some sentences from their WARNING session:
"The ioctl(DP_ISPOLLED) system call also returns its result in the revents member of the pollfd structure, in order to be compatible with the implementation of the /dev/poll driver by some other vendors."
Hopefully this will get fixed.
I also like to reexpress my very negative feelings towards the fact that you're not able to file bug reports when you do not have a support contract. Ridiculous.
Thanks,
bighawk

Have I mentioned how much i love my playbook now Great job on os 2.0

[bdb bug]repeatly open and close db may cause memory leak

my test code is very simple :
char *filename = "xxx.db";
char *dbname = "xxx";
for( ; ;)
DB *dbp;
DB_TXN *txnp;
db_create(&dbp,dbenvp, 0);
dbenvp->txn_begin(dbenvp, NULL, &txnp, 0);
ret = dbp->open(dbp, txnp, filename, dbname, DB_BTREE, DB_CREATE, 0);
if(ret != 0)
printf("failed to open db:%s\n",db_strerror(ret));
return 0;
txnp->commit(txnp, 0);
dbp->close(dbp, DB_NOSYNC);
I try to run my test program for a long time opening and closing db repeatly, then use the PS command and find the RSS is increasing slowly:
ps -va
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
1986 pts/0 S 0:00 466 588 4999 980 0.3 -bash
2615 pts/0 R 0:01 588 2 5141 2500 0.9 ./test
after a few minutes：
ps -va
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
1986 pts/0 S 0:00 473 588 4999 976 0.3 -bash
2615 pts/0 R 30:02 689 2 156561 117892 46.2 ./test
I had read bdb's source code before, so i tried to debug it for about a week and found something like a bug:
If open a db with both filename and dbname, bdb will open a db handle for master db and a db handle for subdb,
both of the two handle will get an fileid by a internal api called __dbreg_get_id, however, just the subdb's id will be
return to bdb's log region by calling __dbreg_pop_id. It leads to a id leak if I tried to open and close the db
repeatly, as a result， __dbreg_add_dbentry will call realloc repeatly to enlarge the dbentry area, this seens to be
the reason for RSS increasing.
Is it not a BUG?
sorry for my pool english :)
Edited by: user9222236 on 2010-2-25 下午10:38

I have tested my program using Oracle Berkeley DB release 4.8.26 and 4.7.25 in redhat 9.0 (Kernel 2.4.20-8smp on an i686) and AIX Version 5.
The problem is easy to be reproduced by calling the open method of db handle with both filename and dbname being specified and calling the close method.
My program is very simple:
#include <stdlib.h>
#include <stdio.h>
#include <sys/time.h>
#include "db.h"
int main(int argc, char * argv[])
int ret, count;
DB_ENV *dbenvp;
char * filename = "test.dbf";
char * dbname = "test";
db_env_create(&dbenvp, 0);
dbenvp->open(dbenvp, "/home/bdb/code/test/env",DB_CREATE|DB_INIT_LOCK|DB_INIT_LOG|DB_INIT_TXN|DB_INIT_MPOOL, 0);
for(count = 0 ; count < 10000000 ; count++)
DB *dbp;
DB_TXN *txnp;
db_create(&dbp,dbenvp, 0);
dbenvp->txn_begin(dbenvp, NULL, &txnp, 0);
ret = dbp->open(dbp, txnp, filename, dbname, DB_BTREE, DB_CREATE, 0);
if(ret != 0)
printf("failed to open db:%s\n",db_strerror(ret));
return 0;
txnp->commit(txnp, 0);
dbp->close(dbp, DB_NOSYNC);
dbenvp->close(dbenvp, 0);
return 0;
DB_CONFIG is like below:
set_cachesize 0 20000 0
set_flags db_auto_commit
set_flags db_txn_nosync
set_flags db_log_inmemory
set_lk_detect db_lock_minlocks
Edited by: user9222236 on 2010-2-28 下午5:42
Edited by: user9222236 on 2010-2-28 下午5:45

Greyscale bug?

Similar Messages

Maybe you are looking for